[Dwarf-Discuss] arm literal pool
davea42 at earthlink.net
Tue Sep 15 10:24:50 PDT 2009
I did not feel like responding to gcc or gdb lists, so this
reply is just in the dwarf-discuss list.
ranjith kumar wrote:
> 1) Given an ARM executable, how to know weather a given address
> contains an 'arm instruction' or 'literal pool' ??
If the DWARF information is appropriately complete and
correct, then the answer is yes.
> 2) What happens when we strip that binary? Can we still determine
> whether given address contains an 'arm instruction' or 'literal
Now the answer depends on whether the remaining information in the binary
is 'complete enough'. For example .debug_frame or
.eh_frame (.eh_frame is not actually DWARF but is similar)
will likely be enough to answer the question. If it is sufficiently
> 3)Can libelf/libdwarf libraries determine whether given address
> contains an 'arm instruction' or 'literal pool' even after that
> library has been stripped? Where can I find sample programs which uses
> libelf/libdwarf libraries and will tell whether given address
> contains an 'arm instruction' or 'literal pool' ?
If stripped, the answer is, as I say above, 'maybe'.
The source to gdb is such a 'sample program' one could look at,
though it does not use libdwarf.
> 4) How debuggers build control flow graph from an executable, when
> 'literal pool' appears in between 'instructions'?
Actually a control flow graph is never necessary for a debugger.
Other tools may want to build such (such as performance-measuring tools)
but debuggers don't need that. Debuggers do need to be able, given
an address, to know what function contains that address (if any function
Well, and other things. But a complete application-wide call
graph is not needed.
Hope this makes sense.
More information about the Dwarf-Discuss