"Maciej W. Rozycki" <macro@xxxxxxxxxxxxxx> writes:
> 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@xxxxxxxxx (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@xxxxxxxxx (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?
>
ld --version
GNU ld (GNU Binutils) 2.18
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
> 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.
Yep:
File: gcl_readline.o
0000000000000928 R_MIPS_GOT_DISP _IO_getc
int rl_getc_em(FILE *f) {
static char *line = NULL;
static int linepos = 0;
int r;
if (f!=stdin || !isatty(fileno(f)) ) return getc(f);
....
>
> 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.
>
This comment was very helpful. I had implemented a stub at the end of
each loaded .o file to read the main stub, discern the got entry, read
it, and jump. Now I skip the stub reading step and use the gotsym and
locgotno from the .dynamic section and the dyn_symtab entries to
compute the got offset. I can now handle symbols with 0 initial
value.
Thanks so much!
> Maciej
>
>
>
>
--
Camm Maguire camm@xxxxxxxxxxxxxxxxx
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
