linux-mips
[Top] [All Lists]

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

To: Camm Maguire <camm@maguirefamily.org>
Subject: Re: [Gcl-devel] Re: gdb for mips64
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Fri, 29 Oct 2010 08:47:36 +0100 (BST)
Cc: David Daney <ddaney@caviumnetworks.com>, linux-mips <linux-mips@linux-mips.org>, debian-mips@lists.debian.org, gcl-devel@gnu.org
In-reply-to: <87vd4mm2hj.fsf@maguirefamily.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <E1OwbkA-0006gv-Bi@localhost.m.enhanced.com> <4C93993E.7030008@caviumnetworks.com> <8762y49k1k.fsf@maguirefamily.org> <4C93D86D.5090201@caviumnetworks.com> <87fwx4dwu5.fsf@maguirefamily.org> <4C97D9A1.7050102@caviumnetworks.com> <87lj6te9t1.fsf@maguirefamily.org> <4C9A8BC9.1020605@caviumnetworks.com> <4C9A9699.6080908@caviumnetworks.com> <87pqvbs7oa.fsf@maguirefamily.org> <4CB88D2C.8020900@caviumnetworks.com> <87r5fksxby.fsf_-_@maguirefamily.org> <4CBF1B1E.6050804@caviumnetworks.com> <8762wwlfen.fsf@maguirefamily.org> <4CC06826.2070508@caviumnetworks.com> <4CC0787C.2040902@caviumnetworks.com> <878w1m3qmn.fsf_-_@maguirefamily.org> <4CC5FA72.6080005@caviumnetworks.com> <87k4l52eqb.fsf@maguirefamily.org> <87vd4or9v9.fsf@maguirefamily.org> <alpine.LFD.2.00.1010281109480.25426@eddie.linux-mips.org> <87vd4mm2hj.fsf@maguirefamily.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Alpine 2.00 (LFD 1167 2008-08-23)
On Thu, 28 Oct 2010, Camm Maguire wrote:

> >  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.

 OK, they should be good I believe, as should be any version newer than 
2.16-ish (I'd have to get at the ChangeLogs to recall exactly when usable 
support for the new ABIs went in), but I suggest an upgrade to the current 
version at your convenience anyway.

> >  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);
> ....

 OK, so that does look like a problem with GCC as this piece of code only 
takes the address of getc() (that is #defined to _IO_getc() in <stdio.h>) 
for the purpose of making a function call.  An R_MIPS_CALL16 relocation 
should therefore be used here instead.

 Would you care to quote the GCC version causing this and get an assembly 
output of the surrounding code (say +/-5 instructions from the 
relocation), preferably one generated by GCC along the lines of:

$ gcc -S -dp <other_options_needed_here> gcl_readline.c

(you can just copy and paste the invocation line quoted by `make' and 
substitute "-c" for "-S -dp" (and gcl_readline.o for gcl_readline.s, if 
applicable) leaving the rest of options intact), but if that turns out too 
difficult, then:

$ objdump -dr gcl_readline.o

might be good enough.

> >  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.

 Hmm, what you're doing sounds odd to me -- are you trying to gather some 
sort of statistics about lazy binding calls or what?  There may be 
functionality to cover this kind of processing already available in ld.so.  
Also once the program has been loaded the dynamic linker will have already 
resolved any strong symbol references and you shouldn't be seeing any that 
still has a null value (that does not apply to weak references that may 
remain unsatisfied).

 Also note that if you're doing stuff manually like this, then you may 
have to take the GOT model used (traditional GOT, xGOT, multi-GOT) into 
account.

> Thanks so much!

 You are welcome!

  Maciej

<Prev in Thread] Current Thread [Next in Thread>