[Dwarf-Discuss] arm literal pool

[David Anderson]

I did not feel like responding to gcc or gdb lists, so this
reply is just in the dwarf-discuss list.

ranjith kumar wrote:
> Hi,
>
> 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
> pool'?
>   
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 
complete and
correct.
> 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 
does).
Well, and other things.    But a complete application-wide call
graph is not needed.

Hope this makes sense.
David Anderson