On Thu, May 17, 2018, 3:31 PM Friedman, Eli <efriedma at codeaurora.org> wrote:> On 5/17/2018 12:22 PM, Kenneth Adam Miller wrote: > > > On Thu, May 17, 2018 at 3:09 PM, Friedman, Eli <efriedma at codeaurora.org> > wrote: > >> On 5/17/2018 10:10 AM, Kenneth Adam Miller via llvm-dev wrote: >> >>> Hello, >>> >>> >>> I've looked around in the documentation, and I can't see anywhere where >>> there is a backend plugin capability for LLVM. I'd like to be able to get >>> the output of the instruction selector along with the LLVM IR, or perhaps >>> instrument that. >>> >>> >>> Is there any capability to have a backend plugin in LLVM at all? >>> >> >> It sounds like you want to write a MachineFunctionPass as a plugin, and >> run it in the middle of the pass pipeline of an existing backend? No, >> there isn't any support for that; RegisterStandardPasses only works on IR. >> >> -Eli >> >> -- >> Employee of Qualcomm Innovation Center, Inc. >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a >> Linux Foundation Collaborative Project >> >> > Yeah, I just discovered MachineFunctionPass. I don't know that I want to > run it in the middle of the pass pipeline of an existing backend so much as > I want the desired target to run and then have my machine function pass > run. If I can get the address of every machine instruction I will be very > happy. > > If you're inserting instrumentation, you need to emit the instrumented > code somehow, which implies the "middle" of the pass pipeline of an > existing backend (although maybe pretty close to the end). And if you're > not inserting instrumentation, I'm not sure what you mean by the "address" > of an instruction. > > -Eli > > -- > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > >By address, I mean the selected location in the binary. I need the ground truth for other static analyses.>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180517/2947ac5b/attachment.html>
Kenneth Adam Miller wrote:> By address, I mean the selected location in the binary. I need the > ground truth for other static analyses.That's not determined until instructions are encoded for the object file, which is pretty deep down in MC. I can imagine a couple of ways to get the info you want, but it's not pretty. You could emit a label for every instruction, and then work out the label offsets later on; you might also be able to collect section offsets as the encoded instructions are emitted to the object file. But really, it seems easier to do a disassembly on the object file, instead of trying to collect the information during compilation. --paulr
On Thu, May 17, 2018 at 6:01 PM, <paul.robinson at sony.com> wrote:> Kenneth Adam Miller wrote: > > By address, I mean the selected location in the binary. I need the > > ground truth for other static analyses. > > That's not determined until instructions are encoded for the object > file, which is pretty deep down in MC. I can imagine a couple of ways > to get the info you want, but it's not pretty. You could emit a label > for every instruction, and then work out the label offsets later on; > you might also be able to collect section offsets as the encoded > instructions are emitted to the object file. > > But really, it seems easier to do a disassembly on the object file, > instead of trying to collect the information during compilation. > --paulr > >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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180517/e1189033/attachment.html>