CODEWITHSUNDEEP
gccdecompilerbinutilsreadelf
lukmac
lukmac

Reputation: 4831

gcc to tell a register compiled from which variable

I need to know from which variable is a register of a binary instruction in the obj file is compiled from.
In short: the mapping from the register to variable for each instruction

Example: suppose objdump gives a snippet of obj file as:

MOV R1 5        # move 5 to register R1
SW R2 SP[-20]   # store the value of R2 to address SP-20

How could we know that R1 stores variable, say, var1 from the source code? And R2 stores var2?

I searched in the documentation of readelf, unfortunately in vain.
(Though it can give me the line mapping between source and binary, it helps me no further)

Then I searched for some debugging options of gcc and the linker. Found some useful info, but they still dont solve my problem.
The info i found is:

Does anyone have some experience or idea?

Thank you all!

hack on ...

Upvotes: 2

Views: 538

Answers (3)

Alexy Khilaev
Alexy Khilaev

Reputation: 444

For this purpose, you can use flags: 

gcc foo.c -da -dp -fdump-tree-all-raw-lineno

Where:

-da produce all RTL dumps

-dp annotate the assembler output with a comment indicating which patterns and alternatives are used.

-fdump-tree-all-raw-lineno Enables showing line numbers for statements.

This will create about 167 files, each of them means different stages of GIMPLE and RTL passes, optimizations and so on. Here is simple explanation is what's going on:

https://www.cse.iitb.ac.in/~uday/courses/cs715-09/gcc-rtl.pdf

Most useful dumps are:

foo.c.227t.optimized
foo.c.229r.expand
foo.c.259r.combine
foo.c.307r.finish

And several others for different purposes.

Upvotes: 0

Ned
Ned

Reputation: 2262

GCC's "-fverbose-asm" option may help a little. It annotates the compiler's output with variable names. Unfortunately, the names are often temporaries invented by the compiler, such as "D.1234". It can still help to give you an idea of what's going on.

Try compiling something simple and take a look:

gcc -g -O0 -S -fverbose-asm foo.c -o foo.s

The way a debugger like GDB figures out where variables are stored at a given point in your program is (for most systems) using DWARF debug information generated by the compiler and stored in the object file. If your system is using DWARF, then readelf will do some very basic interpretation of this information for you. Try this:

readelf --debug-dump=info foo.o

It's clearly not trivial to decode. If you want to have a go, then check out the DWARF standard(s) at http://dwarfstd.org/.

Upvotes: 0

James
James

Reputation: 9278

It's quite common for compiler to produce a mixed assembler/source code listing. It will show the source code it compiled and underneath it will show the generated assembler code. A quick Google gives

http://www.delorie.com/djgpp/v2faq/faq8_20.html

Upvotes: 0

Related Questions