gcl-devel
[Top][All Lists]
Advanced

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

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


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: gdb for mips64
Date: Thu, 28 Oct 2010 17:28:08 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

"Maciej W. Rozycki" <address@hidden> 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 address@hidden 
>> > (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 address@hidden 
>> > (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                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

[Prev in Thread] Current Thread [Next in Thread]