llvm dev - Jun 2019 - Method to map LLVM IR var name to pc address?

Hello,

I have a problem where an two existing LLVM analyses, one at the IR level,
with variable names, and another at the machine code level. I need to map
the IR information down to the resulting binary. I don't want to try and
write a custom algorithm to fit the results of the analysis to the machine
code because across variable renaming and machine code specifics, that
introduces too much room for error and unnecessary additional difficulty. I
do understand that you can specify interaction between passes and I do not
want that for this reason.

Instead, I would like to be able to know where particular variable is
defined at in the final binary in order to map the IR to the result. Does
anybody know of a way to do this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190610/38f42f43/attachment.html>

Hi,

It's not clear what you mean by 'variable name' here.  If you mean 
globals, then they should have the same name in the resulting binary (at 
least, before linking discards them for statics).

If you mean function-local variables, then these names are lost even by 
the time that you get to LLVM IR (though debug info may provide a way of 
recovering them).  You may be able to read both the debug info from the 
binary and from the IR to match them together, but debug info is always 
best effort so this seems unreliable.

If you mean LLVM IR register names, then these typically don't exist at 
all in release builds and do not have a simple mapping to machine 
instructions.  A given IR register may exist on the stack, in a register 
(or both), or be an intermediate result that is produced and consumed in 
the middle of a CISC instruction and never visible outside of hidden 
microarchitectural state.

David


On 10/06/2019 19:27, Kenneth Adam Miller via llvm-dev
wrote:
> Hello,
> 
> I have a problem where an two existing LLVM analyses, one at the IR 
> level, with variable names, and another at the machine code level. I 
> need to map the IR information down to the resulting binary. I don't 
> want to try and write a custom algorithm to fit the results of the 
> analysis to the machine code because across variable renaming and 
> machine code specifics, that introduces too much room for error and 
> unnecessary additional difficulty. I do understand that you can specify 
> interaction between passes and I do not want that for this reason.
> 
> Instead, I would like to be able to know where particular variable is 
> defined at in the final binary in order to map the IR to the result. 
> Does anybody know of a way to do this?
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

I forgot to mention that I have access to the LLVM IR, and that's what
I'm
feeding into the compiler to have different passes run on. I mean function
local variable names at the LLVM IR level.

On Mon, Jun 10, 2019 at 2:27 PM Kenneth Adam Miller <
kennethadammiller at gmail.com> wrote:
> Hello,
>
> I have a problem where an two existing LLVM analyses, one at the IR level,
> with variable names, and another at the machine code level. I need to map
> the IR information down to the resulting binary. I don't want to try
and
> write a custom algorithm to fit the results of the analysis to the machine
> code because across variable renaming and machine code specifics, that
> introduces too much room for error and unnecessary additional difficulty. I
> do understand that you can specify interaction between passes and I do not
> want that for this reason.
>
> Instead, I would like to be able to know where particular variable is
> defined at in the final binary in order to map the IR to the result. Does
> anybody know of a way to do this?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190611/b6e7763c/attachment-0001.html>