Re: [patch] Fix separate-debug with non-unique section names (PR 11409)

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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