<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 17, 2018 at 6:01 PM,  <span dir="ltr"><<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Kenneth Adam Miller wrote:<br>
> By address, I mean the selected location in the binary. I need the<br>
> ground truth for other static analyses.<br>
<br>
</span>That's not determined until instructions are encoded for the object<br>
file, which is pretty deep down in MC.  I can imagine a couple of ways <br>
to get the info you want, but it's not pretty.  You could emit a label<br>
for every instruction, and then work out the label offsets later on;<br>
you might also be able to collect section offsets as the encoded<br>
instructions are emitted to the object file.<br>
<br>
But really, it seems easier to do a disassembly on the object file,<br>
instead of trying to collect the information during compilation.<br>
--paulr<br>
<br></blockquote><div><br></div><div>Disassembly is undecidable, that's why the ground truth from the compiler is so desireable. Even with debug symbols, there can be code fragments that exist beyond the visible terminator of a function boundary, or functions that are not aligned so that linear sweep can have false negatives. It's hard to validate binary corpora against anything else, because even with symbol information, all you can get is the function entrance. The dwarf debug info is even harder to retrieve as a list of addresses, because that's such an arbitrary and skeletal API that is used by different languages very very differently.</div></div><br></div></div>