[Cbe-oss-dev] SPU overlay DWARF DIE/CIE/FDE to program section/segment mapping?

[Ulrich Weigand]

John DelSignore wrote:

> Question: Is there a way to determine the program segment to which a
> particular DWARF DIE or CIE/FDE belongs, when multiple program 
> segments are linked at the same address due to SPU overlays?

Not easily.

> Loader symbols which are associated with a particular program 
> segment are defined together in a single file section, and the file 
> section header includes a "phoff" field, which, as we understand 
it,indicates
> the offset within the executable file of the associated program 
> segment.  For example:
> 
> ------------------------------cut-here------------------------------
> % readelf -s spu_main | egrep Num\|_test
>    Num:    Value  Size Type    Bind   Vis      Ndx Name
>     66: 00000b00    60 FUNC    GLOBAL DEFAULT    3 o1_test1
>     70: 00000b40    60 FUNC    GLOBAL DEFAULT    4 o2_test2
>     86: 00000b40    60 FUNC    GLOBAL DEFAULT    3 o1_test2
>     92: 00000b00    60 FUNC    GLOBAL DEFAULT    4 o2_test1
> % 
> ------------------------------cut-here------------------------------
> 
> We can take the section index (in the Ndx column), get the section 
> file offset, and then lookup the program header. That makes it 
> straightforward to determine the overlay to which a particular 
> loader symbol belongs.

Yes, exactly.

> However, the DWARF information does not seem to contain any direct 
> indication of the program segment to which a particular symbol 
> belongs. Only the link address of the symbol is provided in the 
> DWARF information, and when multiple segments are linked at the same
> address, that's ambiguous.  That seems to make it impossible to 
> determine which overlay a particular DWARF symbol belongs to. For 
> example, here are some DWARF DIEs for the sample program functions 
> o1_test1() and o2_test1(), both of which are at virtual address 
0x00000b00:

That's true.  What GDB does is to use the symbol name from DWARF
symbol information, and go back to the loader symbol data for the
symbol with the same name, and use the section index from there
to determine the overlay where the symbol resides.

> The DWARF frame information has a similar problem:
[snip]
> Notice that the FDE pc ranges overlap

That's also correct.  What GDB does is to fall back to prologue
analysis for functions in overlay sections ... this is clearly not
ideal, but probably better than nothing.

> Without the connection between the DWARF symbol and the segment, 
> it's difficult or impossible to manage breakpoints within and 
> properly back trace out of code which is in an overlay. The reason 
> for this is that we want to be able to take each link address in the
> executable file and relocate it into separate provisional address 
> space. Each program object (subroutine, variable, etc.) lives at a 
> unique location in the provisional address space, which allows a 
> unique mapping between provisional addresses and symbols.
> 
> What we need is a way to map an address in a DWARF DIE or CIE/FDE to
> a particular section or program segment so that we can determine the
> proper provisional relocation value.
> 
> Does such a mapping exist?

Unfortunately, there is no easy way to do that right now.   If special 
builds
are acceptable, you might build your SPU executable with the --emit-relocs
linker option.  This will keep relocation information in the final 
executable.

You could then examine the reloc data to find out the symbols that were
used to detemine the final addresses in DWARF DIE and CIE/FDE sections.
Once you have the symbol, you can go back to the section index that is
kept in the symbol table to determine the overlay region to use.

Otherwise, I'm not sure there's anything better than the tricks GDB
does use to handle overlays ...

> Finally, as far as we can tell, breakpoint handling in overlaid SPU 
> segments in ppu-gdb just flat out doesn't work:

Hmm, it's not perfect, but basic support should be there.

However, you need to manually switch on overlay support by issuing
the "overlay auto" command before starting the executable.  GDB will
not do this automatically right now.

If you find any other issues with GDB overlay support, or have some
more questions, I'll be happy to look into it.


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

-- 
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
  IBM Deutschland Research & Development GmbH
  Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Erich 
Baier
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht 
Stuttgart, HRB 243294