This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: Regression caused by elfread.c patch
- To: akale at veritas dot com (Amit S. Kale)
- Subject: Re: Regression caused by elfread.c patch
- From: Todd Whitesel <toddpw at windriver dot com>
- Date: Tue, 15 Feb 2000 12:07:08 -0800 (PST)
- Cc: toddpw at windriver dot com (Todd Whitesel), kingdon at redhat dot com (Jim Kingdon), akale at veritas dot com, kettenis at wins dot uva dot nl, gdb at sourceware dot cygnus dot com, gdb-patches at sourceware dot cygnus dot com
> I guess gdb first prepares text, data, bss segments and following code
> bfd/section.c:bfd_make_section_anyway():
> newsect->index = abfd->section_count++;
> indicates that section->index contains SECT_OFF_* codes when segments are
> loaded. This may not have been designed this way, but it seems to be that way.
Yes, this looks like a desperate attempt to deal with the fundamental
numbering conflict that currently exists.
Any time stabs are read, much of GDB assumes that ANOFFSET takes SECT_OFF_*
values, even in cases where you'd expect it to take BFD section indices. So
anyone actually attempting to use BFD indices for real is plagued by subtle
bugs.
> Using sym->section->index is not right for segments that are not text or data
> segments. Using sym->section->index should be all right for data segments.
It depends on the path through the *_symfile_offsets code that is taken.
symtab.h explicitly claims that the section numbers in ANOFFSET are
"file-type-dependent" but this is largely ignored by the rest of GDB.
> I suggest following patch. I have verified that the vfprintf problem reported
> by Mark does not appear with this patch. I haven't tested it with test suite.
I guarantee you it won't completely solve the problem. But if the test suite
uses fully-linked programs, it will end up passing the tests anyway because
ANOFFSET returns 0 for all sections when a file is fully linked.
> > However, so few configurations (read: vxWorks and ??) actually use different
> > offsets for, say, SECT_OFF_TEXT and SECT_OFF_DATA, that no one notices the
> > problems with it. (We read relocatable .o files too, which is also rare.)
>
> It won'd be rare when gdb will be used by more people to debug linux kernel
> modules.
I hope you've got patches to symbol_file_add() and *_symfile_offsets to
accept more than one address offset for the section_offsets->offsets array.
If not, then any section loaded independently from .text is going to have
mucho problems being relocated by GDB.
--
Todd Whitesel
toddpw @ windriver.com