Re: Regression caused by elfread.c patch

[Todd Whitesel <toddpw at windriver 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