On Feb 16 10:46, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> Back to the drawing board…  The section names in rebase are completely
> >> different,
> >
> > "completely different"?  -v, please?
> 
> I gave up in disgust… anyway, instead of the .debug_* section names,
> rebase finds something like "/19".  I can't find a way to have objdump
> use the same format.  Objcopy does have an option that hints at some
> "long section names" that can be present and I surmise that the debug
> sections use such names.
> 
> >> not sure how I should get objdump to display them.
> >
> > objdump -h?
> 
> Nope.  That tells you:
> 
> Sections:
> Idx Name          Size      VMA               LMA               File off  Algn
> [...]
>  10 .debug_aranges 00000220  00000003e541e000  00000003e541e000  00006200  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  11 .debug_info   0000cc86  00000003e541f000  00000003e541f000  00006600  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  12 .debug_abbrev 00000e74  00000003e542c000  00000003e542c000  00013400  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  13 .debug_line   00000e93  00000003e542d000  00000003e542d000  00014400  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  14 .debug_frame  00000350  00000003e542e000  00000003e542e000  00015400  2**3
>                   CONTENTS, READONLY, DEBUGGING
>  15 .debug_loc    00000b22  00000003e5430000  00000003e5430000  00015800  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  16 .debug_ranges 000000c0  00000003e5431000  00000003e5431000  00016400  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  17 .debug_str    000001a8  0000000400000000  0000000400000000  00016600  2**0
>                   CONTENTS, READONLY, DEBUGGING
> 
> While rebase thinks:
> 
> Base:       0x0x2f0000
> ImageBase:  0x3e2660000
> ImageBase: 0x3e2660000 ImageSize: 0x22000
> [...]
>    section name:       /4 base: 0x0000e000 size: 0x00000400 file offset: 0x00006200 offset: 0x002e8200
>    section name:      /19 base: 0x0000f000 size: 0x0000ce00 file offset: 0x00006600 offset: 0x002e7600
>    section name:      /31 base: 0x0001c000 size: 0x00001000 file offset: 0x00013400 offset: 0x002e7400
>    section name:      /45 base: 0x0001d000 size: 0x00001000 file offset: 0x00014400 offset: 0x002e7400
>    section name:      /57 base: 0x0001e000 size: 0x00000400 file offset: 0x00015400 offset: 0x002e7400
>    section name:      /70 base: 0x0001f000 size: 0x00000200 file offset: 0x00015800 offset: 0x002e6800
>    section name:      /81 base: 0x00020000 size: 0x00000c00 file offset: 0x00015a00 offset: 0x002e5a00
>    section name:      /92 base: 0x00021000 size: 0x00000200 file offset: 0x00016600 offset: 0x002e5600

Uh, ok.  These look like decimal offsets into a string table.  I'm just
not sure where the base (the string table) is.  I'll ask a collegue.

> > So it's not about the debug sections, apparently.  It was just a guess
> > anyway.
> 
> It still is about the debug sections…  They are still present in the
> rebased object files, but nm and objdump don't associate the information
> in them with the code anymore.  The same thing already happens when I
> just change the ImageBase, so it seems that rebase would somehow also
> have to change something in the debug records, albeit it's entirely
> unclear what that might be.

The only thing I can think of:  The debug sections contain pointers to
symbols, code, etc.  Either these are absolute, which makes them depend
on the executable being loaded exactly in the same spot as it were based
to when building the executable, or they are relative to a base and the
base is stored separately from the VMA.

I don't know the internals of the dwarf2 format well enough, so this is
just an (un?)educated guess.  Again, I'll ask a collegue.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat