unresoved symbol _gp_disp

unresoved symbol _gp_disp

[veerasena reddy]

Hi,

  I am using buildroot to build toolchain (GCC ver
3.4.3, binutil-1.15 and ucLibc-0.9.28, linux-2.6.18
kernel) for MIPS processor with soft float option
enabled.

I have written a loadble module ( which gets complied
along with kernel) which does some floating point
operation.
 
When i try to load the module i get the following
error
"unresoved symbol _gp_disp".
===================================================
below is from MIPS FAQ which also doesn't help:

Insmod complains about the _gp_disp symbol being
undefined
_gp_disp is a magic symbol used with PIC code on MIPS.
Be happy, this error message saved you from crashing
your system. You should use the same compiler options
to compile a kernel module as the kernel makefiles do.
In particular the options -mno-pic -mno-abicalls -G 0
are important.
===================================================
 
In fact i tried with -mno-abicalls -fno-pic  compiler
options still i see the same problem.
 
Could you please give me some pointers on this issue.
BTW, How to compile libgcc.a with "-G 0" options.
In which file of buildroot i shoul added these options
to get effective.
 
Thanks in advance.
 
Regards,
Veerasena.


      Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/

Re: unresoved symbol _gp_disp

[Steven J. Hill]

> I have written a loadble module ( which gets complied
> along with kernel) which does some floating point
> operation.
>  
NO FLOATING POINT in the kernel PERIOD. Either use integer
operations, or redo your software architecture and do the
floating point in userspace.

-Steve

Re: unresoved symbol _gp_disp

[David Daney]

Steven J. Hill wrote:
>> I have written a loadble module ( which gets complied
>> along with kernel) which does some floating point
>> operation.
>>  
> NO FLOATING POINT in the kernel PERIOD.

Unless you compile your code with -msoft-float *and* also have a version 
of libgcc compiled with -mlong-calls -mno-abicalls -G0.  If you do it 
that way, floating point works fine in the kernel (as long as you don't 
try to call sprintf with floating point parameters).


> Either use integer
> operations, or redo your software architecture and do the
> floating point in userspace.
> 
> -Steve
> 

Re: unresoved symbol _gp_disp

[Steven J. Hill]

> Unless you compile your code with -msoft-float *and* also have a version 
> of libgcc compiled with -mlong-calls -mno-abicalls -G0.  If you do it 
> that way, floating point works fine in the kernel (as long as you don't 
> try to call sprintf with floating point parameters).
> 
I won't even concede that solution. It's bad practice and design to have
floating point in the kernel.

-Steve

Re: unresoved symbol _gp_disp

[Andi Kleen]

"Steven J. Hill" <sjhill@realitydiluted.com> writes:

> > I have written a loadble module ( which gets complied
> > along with kernel) which does some floating point
> > operation.
> >  
> NO FLOATING POINT in the kernel PERIOD. Either use integer
> operations, or redo your software architecture and do the
> floating point in userspace.

You can use floating point; you just have to make sure to 
save the FP context explicitely and disable preemption. Details
on how to do this vary by architecture.

The problem is that FP code typically takes often a lot of CPU time
and it is quite antisocial to disable preemption for a long time
because that impacts real time latency for everybody.

Besides many uses can be relatively easily rewritten to fixed
point.

-Andi

Re: unresoved symbol _gp_disp

[David Daney]

Steven J. Hill wrote:
>> Unless you compile your code with -msoft-float *and* also have a version 
>> of libgcc compiled with -mlong-calls -mno-abicalls -G0.  If you do it 
>> that way, floating point works fine in the kernel (as long as you don't 
>> try to call sprintf with floating point parameters).
>>
> I won't even concede that solution. It's bad practice and design to have
> floating point in the kernel.

I agree that floating point in the kernel is bad practice.  However 
under some circumstances, the most expedient solution does not conform 
to best practice.

David Daney

Re: unresoved symbol _gp_disp

[Ralf Baechle]

On Thu, Oct 04, 2007 at 08:29:59PM +0200, Andi Kleen wrote:
> From: Andi Kleen <andi@firstfloor.org>
> Date: 04 Oct 2007 20:29:59 +0200
> To: "Steven J. Hill" <sjhill@realitydiluted.com>
> Cc: veerasena reddy <veerasena_b@yahoo.co.in>,
> 	linux-mips <linux-mips@linux-mips.org>,
> 	"linux-kernel.org" <linux-kernel@vger.kernel.org>
> Subject: Re: unresoved symbol _gp_disp
> Content-Type: text/plain; charset=us-ascii
> 
> "Steven J. Hill" <sjhill@realitydiluted.com> writes:
> 
> > > I have written a loadble module ( which gets complied
> > > along with kernel) which does some floating point
> > > operation.
> > >  
> > NO FLOATING POINT in the kernel PERIOD. Either use integer
> > operations, or redo your software architecture and do the
> > floating point in userspace.
> 
> You can use floating point; you just have to make sure to 
> save the FP context explicitely and disable preemption. Details
> on how to do this vary by architecture.
> 
> The problem is that FP code typically takes often a lot of CPU time
> and it is quite antisocial to disable preemption for a long time
> because that impacts real time latency for everybody.
> 
> Besides many uses can be relatively easily rewritten to fixed
> point.

He said he was using software floating point which from a kernel perspective
really just is integer stuff anyway.

Hardware floating point in a MIPS kernel would be require solving a few
interesting problems; the kernel floating point assist software is only
designed to support userspace.  Or alternativle well written FP code
that avoids all the corner cases which would normally be handled by the
kernel fp software.

The biggest argument against floating point use in the kernel is that most
of the time it's an indicator for poor division of work between kernel
and userspace.

  Ralf

Re: unresoved symbol _gp_disp

[Ralf Baechle]

On Thu, Oct 04, 2007 at 11:32:59AM -0700, David Daney wrote:

> Steven J. Hill wrote:
> >>Unless you compile your code with -msoft-float *and* also have a version 
> >>of libgcc compiled with -mlong-calls -mno-abicalls -G0.  If you do it 
> >>that way, floating point works fine in the kernel (as long as you don't 
> >>try to call sprintf with floating point parameters).
> >>
> >I won't even concede that solution. It's bad practice and design to have
> >floating point in the kernel.
> 
> I agree that floating point in the kernel is bad practice.  However 
> under some circumstances, the most expedient solution does not conform 
> to best practice.

I also feel deeply unfriendly if I send somebody along a path that's
full of interesting corner cases ...

  Ralf