Re: [Gcl-devel] Re: gdb for mips64
On Tue, 26 Oct 2010, Camm Maguire wrote:
> > Why doesn't _IO_getc get a stub on mips64, like say _setjmp?
> >
> > readelf -a saved_ansi_gcl |grep IO_getc
> > 2812: 0000000000000000 472 FUNC GLOBAL DEFAULT UND _IO_getc@GLIBC_2.0 (2)
> > 15315: 0000000000000000 472 FUNC GLOBAL DEFAULT UND _IO_getc@@GLIBC_2.0
> > readelf -a saved_ansi_gcl |grep setjmp
> > 2159: 00000001204b9b40 32 FUNC GLOBAL DEFAULT UND _setjmp@GLIBC_2.0 (2)
> > 15978: 00000001204b9b40 32 FUNC GLOBAL DEFAULT UND _setjmp@@GLIBC_2.0
> >
> > Is there anything I can do about this?
> >
>
> A little more info here. Latest toolchain on the gcc compile farm
> does provide a stub, but the slightly older gentoo on a sicortex
> machine does not. Clearly not too much to worry about unless you
> might know of an easy workaround.
Can you quote what `ld --version' says on the affected system?
It *might* be a linker bug, though the exact circumstances may be
complicated as I have n64 MIPS64 binaries as old as from mid 2005 with a
stub for _IO_getc() correctly installed. Nobody should be using any older
binutils, especially with the MIPS64 target as 64-bit support for MIPS was
quite immature back then. I suggest that you switch to binutils 2.20.1;
version 2.21 is due out in a couple of weeks too.
A legitimate cause for a stub to be omitted by the linker are pointer
references to the function in question as in this case the symbol has to
be fully resolved for pointer comparison to produce reliable results. It
could be that one version of GCC produces code that looks to the linker as
if referring to the symbol this way (i.e. the object files presented to
the linker contain relocations normally used for data references rather
than function calls associated with the symbol in question). You can
determine if that is the case by running `objdump -r' on the program's
object files used in the final link and checking if there are any GOT
relocations (that'll be a part of their names, e.g. R_MIPS_GOT_PAGE)
against _IO_getc. Again, that *might* be a GCC bug then.
That said the only impact from a missing stub is a small program startup
performance penalty as lazy binding cannot be applied to this single
symbol only and the symbol has to be fully resolved at startup.
Maciej
Reply to: