[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Gcl-devel] Re: gdb for mips64

"Maciej W. Rozycki" <macro@linux-mips.org> 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@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?

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.


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

Thanks so much!

>   Maciej

Camm Maguire			     		    camm@maguirefamily.org
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Reply to: