Re: [patch] Fix regression on prelinked executables

Joel Brobecker
2010-07-29T16:37:04Z

> Curiously GDB already uses at
> many places
> baseaddr = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile));
> instead of using offset for the appropriate section at that place and nobody
> complains.

It's something I actually noticed almost 10 years ago, now, while
working on Tru64, I think. But I never really found a situation that
required me to work on that, so...

> gdb/
> 2010-07-15 Jan Kratochvil <jan.kratochvil@redhat.com>
>
> * symfile.c (addr_section_name): New function.
> (addrs_section_compar): Use it.
> (addr_info_make_relative): Use it. Move variable sect_name into a more
> inner block. Make ".dynbss" and ".sdynbss" checks more strict.

I think that this is OK.

I'm not sure about putting it on the 7.2 branch, however. Given that
this can directly affect Darwin, I'd rather give this patch an observation
period and potentially put it in 7.2.1.

> gdb/testsuite/
> 2010-07-15 Jan Kratochvil <jan.kratochvil@redhat.com>
>
> * gdb.base/prelink-lib.c (copyreloc): New initialized variable.
> * gdb.base/prelink.c (copyreloc, bssvar, bssvarp): New variables.
> (main): Use copyreloc.
> * gdb.base/prelink.exp (split debug of executable)
> (.dynbss vs. .bss address shift): New tests.

This part is OK.

> if (!(strcmp (sect_name, ".gnu.liblist") == 0
> || strcmp (sect_name, ".gnu.conflict") == 0
> - || strcmp (sect_name, ".dynbss") == 0
> - || strcmp (sect_name, ".sdynbss") == 0))
> + || (strcmp (sect_name, ".bss") == 0
> + && i > 0
> + && strcmp (addrs->other[i - 1].name, ".dynbss") == 0
> + && addrs_to_abfd_addrs[i - 1] != NULL)
> + || (strcmp (sect_name, ".sbss") == 0
> + && i > 0
> + && strcmp (addrs->other[i - 1].name, ".sdynbss") == 0
> + && addrs_to_abfd_addrs[i - 1] != NULL)))

I had to think over this for a while, and I think that the two new checks
are correct. However, I'm still trying to figure out why it's correct
to also remove the simple check for .dynbss. In other words, if .dynbss
is missing from the separate debug object file, shouldn't we emit a
warning?

--
Joel