Corinna Vinschen writes:
> Hang on. Perhaps I just missed the crucial point here, but it just
> occured to me that the DLLs are rebased as part of the autorebase
> script.
Yes, they routinely are. Even on 64bit when they have been
auto-image-based originally.
> So what you have is a DLL which gets some automatic address at build
> time. Then the debug information is split off. At this point, is the
> debug information usable?
I assume yes, but I don't really know how to check. In any case, that's
the way it has been for quite some time.
/usr/bin/cygperl5_14.dll: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0014b2a0 00000003ed741000 00000003ed741000 00000400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 00003028 00000003ed88d000 00000003ed88d000 0014b800 2**6
CONTENTS, ALLOC, LOAD, DATA
2 .rdata 00021a24 00000003ed891000 00000003ed891000 0014ea00 2**6
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .buildid 00000035 00000003ed8b3000 00000003ed8b3000 00170600 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .pdata 00005364 00000003ed8b4000 00000003ed8b4000 00170800 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .xdata 000064c0 00000003ed8ba000 00000003ed8ba000 00175c00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .bss 000002b0 00000003ed8c1000 00000003ed8c1000 00000000 2**6
ALLOC
7 .edata 0000b3e9 00000003ed8c2000 00000003ed8c2000 0017c200 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .idata 00002008 00000003ed8ce000 00000003ed8ce000 00187600 2**2
CONTENTS, ALLOC, LOAD, DATA
9 .reloc 00001464 00000003ed8d1000 00000003ed8d1000 00189800 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 .gnu_debuglink 00000018 00000003ed8d3000 00000003ed8d3000 0018ae00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
/usr/lib/debug/usr/bin/cygperl5_14.dll.dbg: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0014b2a0 00000004d1891000 00000004d1891000 00000000 2**4
ALLOC, LOAD, READONLY, CODE, DATA
1 .data 00003028 00000004d19dd000 00000004d19dd000 00000000 2**6
ALLOC, LOAD, DATA
2 .rdata 00021a24 00000004d19e1000 00000004d19e1000 00000000 2**6
ALLOC, LOAD, READONLY, DATA
3 .buildid 00000035 00000004d1a03000 00000004d1a03000 00000600 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .pdata 00005364 00000004d1a04000 00000004d1a04000 00000000 2**2
ALLOC, LOAD, READONLY, DATA
5 .xdata 000064c0 00000004d1a0a000 00000004d1a0a000 00000000 2**2
ALLOC, LOAD, READONLY, DATA
6 .bss 000002b0 00000004d1a11000 00000004d1a11000 00000000 2**6
ALLOC
7 .edata 0000b3e9 00000004d1a12000 00000004d1a12000 00000000 2**2
ALLOC, LOAD, READONLY, DATA
8 .idata 00002008 00000004d1a1e000 00000004d1a1e000 00000000 2**2
ALLOC, LOAD, DATA
9 .reloc 00001464 00000004d1a21000 00000004d1a21000 00000000 2**2
ALLOC, LOAD, READONLY, DATA
10 .debug_aranges 000009b0 00000004d1a23000 00000004d1a23000 00000800 2**4
CONTENTS, READONLY, DEBUGGING
11 .debug_info 00261e08 00000004d1a24000 00000004d1a24000 00001200 2**0
CONTENTS, READONLY, DEBUGGING
12 .debug_abbrev 0000ddc9 00000004d1c86000 00000004d1c86000 00263200 2**0
CONTENTS, READONLY, DEBUGGING
13 .debug_line 0004ed6e 00000004d1c94000 00000004d1c94000 00271000 2**0
CONTENTS, READONLY, DEBUGGING
14 .debug_frame 00022378 00000004d1ce3000 00000004d1ce3000 002bfe00 2**3
CONTENTS, READONLY, DEBUGGING
15 .debug_str 00004ebb 00000004d1d06000 00000004d1d06000 002e2200 2**0
CONTENTS, READONLY, DEBUGGING
16 .debug_loc 00289775 00000004d1d0b000 00000004d1d0b000 002e7200 2**0
CONTENTS, READONLY, DEBUGGING
17 .debug_ranges 000568b0 00000004d1f95000 00000004d1f95000 00570a00 2**0
CONTENTS, READONLY, DEBUGGING
18 .gnu_debuglink 0000000c 00000004d1fec000 00000004d1fec000 005c7400 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
> Then somebody installs the package and autorebase rebases the DLL
> /usr/bin/foo.dll. But it does not rebase the debug info for the DLL
> /usr/lib/debug/usr/bin/foo.dll.dbg.
Again, my impression so far had been that there is nothing to rebase
there. Even if you did, rebase doesn't touch the data in those
sections, it just changes the image base.
> If the /usr/lib/debug/usr/bin/foo.dll.dbg file is rebased to the same
> address as /usr/bin/foo.dll, shouldn't that "fix" the issue?
I would rather suspect it produces exactly the same problem it does with
the full DLL.
> If that's really the issue, I'm wondering if that can be fixed or
> worked around in GDB. If that's too much hassle, we should probably
> start rebasing the debug info in /usr/lib/debug as well. That
> only requires some small hacking of rebase.
As long as the debug information is made unuseable by doing the rebase,
I don't see why we should start rebasing the debug files. AFAIK, if we
keep them non-rebased then everything works fine or we'd have heard
complaints by now. I only recognized that there was something going on
because I need to rebase the DLL for Perl modules before I can test them
(on 32bit at least) and when cygport later packaged the files it didn't
find any debug information in them anymore (again the information is
still there and has indeed not been altered, but nm doesn't output it
along with the symbols and so cygport assumes they aren't there).
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
