ELF program header table in MiniDebugInfo files

[John Reiser]

On 06/05/2013 05:42 AM, Jan Kratochvil wrote:
> On Tue, 04 Jun 2013 16:19:17 +0200, Martin Milata wrote:

>> My question is, is the table supposed to
>> look like this and libunwind needs to be patched, or is it a bug?

> Segments are irrelevant for symbols.

There is a problem with objdump and MiniDebugInfo and gdb treating ElfXX_Phdr
records as "don't care".  The problem is that other parts of the debugging
environment, including libunwind and humans, *do* care.  The lack of inter-
operability of the ElfXX_Phdr structs that are contained in "symbol table files"
is a Usability bug.  A program should not put "bad data" into the Execution View
just because the program itself uses only the Linking View.  Bad data creates
complexity and confusion, and lengthens debugging time.  libunwind is an example.


Ob gdb: Often I must debug a process that contains "shared objects"
that were loaded into the address space using a mechanism other than dlopen.
(So "info shared" does not help because it is unaware.)
It would be much better if I could say "add-symbol-file NAME &ElfXX_Ehdr"
(because &ElfXX_Ehdr is relevant and easily known by me)
but instead gdb requires "add-symbol-file NAME &.text".
Thus I must "shell objudmp --section-headers NAME  |  grep .text",
select the offset, then add to the base address.  This is doubly tedious
because gdb requires a literal constant and does not accept an expression
for the ADDR.   (Or if already prelinked into the right spot, then I can
choose the LMA to avoid the addition.)

The moral is:  Be nice to the downstream users of the data that you create.
Honor the conventions of *all* the structs that you create, not just
the ones that you yourself use.

--