This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Section garbage collection and function addresses
- To: cmorrow at YottaYotta dot com
- Subject: Re: [ECOS] Section garbage collection and function addresses
- From: Bart Veer <bartv at redhat dot com>
- Date: Wed, 2 Aug 2000 17:32:01 +0100
- CC: ecos-discuss at sourceware dot cygnus dot com
- References: <39873E29.E40F2EB5@YottaYotta.com>
- Reply-to: bartv at redhat dot com
>>>>> "Chris" == Chris Morrow <cmorrow@YottaYotta.com> writes:
Chris> This is appears to be a compiler issue, but I thought some
Chris> people here might find this of interest.
More accurately, it sounds like a linker problem.
Chris> I'm using gdb 4.18, gcc 2.95 and binutils 2.10, all
Chris> configured as mips64-unknown-elf.
Chris> Examining a linked program with objdump show nothing out of
Chris> the ordinary. Using gdb on the linked file in elf format
Chris> mostly works, however some functions are reported as having
Chris> an address of 0. Functions towards the start of the text
Chris> section are okay, but after some point every function has
Chris> an address of zero.
Chris> Turning off -gc-sections on the linker removes this
Chris> problem.
Chris> Objdump -g also appears to be broken.
The main question is, are these functions actually present in the
final executable?
The desired effect of -gc-sections is that any functions not used
directly or indirectly by the application get stripped out. It is
possible that the functions with a reported address of 0 have actually
been removed completely from the final executable, but the debug
information was not cleaned out correctly - the code and the debug
info are stored in separate parts of the object and executable files,
so there is a possibility that they can get out of sync. If a function
has been garbage collected but there is still a debug entry for it, a
reported address of 0 is quite likely.
If a function has not been garbage collected but is still reported
with an address of 0, the problem is more serious.
Anyway, I suggest reporting the problem to the binutils folks at
http://sources.redhat.com/binutils/ They may be able to help.
Bart Veer // eCos net maintainer