This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix separate-debug with non-unique section names (PR 11409)
On Wed, 24 Mar 2010 20:02:07 +0100, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
>
> Jan> gdb-7.1 is now broken for example for debugging /usr/bin/emacs due to:
> Jan> http://sourceware.org/bugzilla/show_bug.cgi?id=11409
> Jan> [22] .data PROGBITS 00000000007fe8a0 1fe8a0 215068 00 WA 0 0 32
> Jan> [23] .data PROGBITS 0000000000a13920 413920 68c6e0 00 WA 0 0 32
>
> Jan> 2010-03-23 Jan Kratochvil <jan.kratochvil@redhat.com>
> Jan> * symfile.c (addr_info_make_relative): Move sect declaration to the
> Jan> outer block. Initialize it to NULL. Prefer SECT->next more than
> Jan> bfd_get_section_by_name.
>
> This patch seems to assume that all sections of the same name will be
> next to each other in the section_addr_info. Why is it ok to make this
> assumption?
The code generally assumes the sections in .debug file are in the same order
as in the main file. Only if there is some discrepancy it will resync by
bfd_get_section_by_name. The resync should not normally happen. Attached an
illustrative /bin/bash -> /usr/lib/debug/bin/bash.debug section diff. The
only resynchronizations happen there on system part of sections - and these
have unique name.
The problem is I do not know how to match sections main<->.debug file when
their name is not unique. One could check VMAs but - to find the difference
of VMAs is the goal of this function.
Assuming for executables + shared libraries there are never many sections
there. This emacs .data section duplicity is more an exception. The only
cases with many (thousands of) sections I am aware of are object files but
object files should get into addr_info_make_relative at all (I hope the Mach-O
support does not use it for the .o symbols loading).
ld --split-by-file=1 creates section names like .text.0 ... .text.1454 all
unique; by bfd_get_unique_section_name.
While the algorithm could be much more clever - if we ever need to resync at
the point of non-unique section names the files are too different it makes no
sence to try to match them by addr_info_make_relative at all.
I may have forgot about this case, not sure, but I do not find it a problem.
Thanks,
Jan
-------------------
.interp
.note.ABI-tag
.note.gnu.build-id
.gnu.hash
.dynsym
-.gnu.liblist
-.gnu.conflict
+.dynstr
.gnu.version
.gnu.version_r
.rela.dyn
.rela.plt
.init
.plt
.text
.fini
.rodata
.eh_frame_hdr
.eh_frame
.ctors
.dtors
.jcr
.dynamic
.got
.got.plt
.data
-.dynbss
.bss
-.dynstr
-.gnu_debuglink
-.gnu.prelink_undo
+.comment
+.debug_aranges
+.debug_pubnames
+.debug_info
+.debug_abbrev
+.debug_line
+.debug_str
+.debug_loc
+.debug_pubtypes
+.debug_ranges
.shstrtab
+.symtab
+.strtab