bug-binutils
[Top][All Lists]
Advanced

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

Re: Assembler unable to handle relative offsets in PIC code under cross-


From: Ayonam Ray
Subject: Re: Assembler unable to handle relative offsets in PIC code under cross-compiling env.
Date: Thu, 9 Feb 2006 18:19:34 +0530 (IST)

Hi Nick,

Firstly, thanks for taking this up.

I'm using gcc version 3.2.2 and I think I also gave a try with 3.4.3 also.  
I'll verify this and get back to you.

I didn't notice it earlier that there is an additional .section directive in 
between.  So your analysis of the error message is right on the point.

However, the surprising thing is that it works with the 64-bit build of the
same assembler code while it fails with the 32-bit build.  So I think that
somewhere there is a difference in the runtime architectures of 32-bit and
64-bit which is hitting us here.  I was guessing it to be a case of 64-bit
porting issue but from your analysis it doesn't seem plausible.

I used the 3.2.2 compiler to generate 32-bit code for the same source and the 
same jump table looks like:

    .section    .rodata
    .align 4
    .align 4
.L6406:
    .long   address@hidden
    .long   address@hidden
    .long   address@hidden
    .long   address@hidden
    .long   address@hidden
    .long   address@hidden
    .long   address@hidden
    .long   address@hidden
    .section    
.gnu.linkonce.t._ZNK6Layout12StdTransformIiE9transformIdEEKNS_5PointIT_EERS6_
.L6398:
    .loc 72 295 0
    movl    16(%ebp), %eax

What I see is that the contents of the table are generated by a different
method (@GOTOFF style directives and not by computing the difference of the
offsets and adding it to the current address).  Probably that's what the
assembler would ultimately do but the assembly directive is not the same.

So could it be that the assembler is assuming that it is compiling for 32-bit
environment and expecting the @GOTOFF kind of directives and instead it is
getting the difference type ones.  I'm just guessing!

Thanks again
Regards
Ayonam


On Thu, 9 Feb 2006, Nick Clifton wrote:

> Hi Ayonam,
> 
> > The assembly fragment in question looks like this:
> > 
> >     .section    .rodata
> > .L5465:
> >     .long   .L5457-.+(.-.L5465)
> >     .long   .L5458-.+(.-.L5465)       <<<<<<- Problem first reported here
> 
> >     .section    
> > .gnu.linkonce.t._ZNK6Layout12StdTransformIiE9transformIdEEKNS_5PointIT_EERS6_
> > .L5458:
> 
> The problem is that the two symbols (.L5458 and .L5465) are in different 
> sections.  Therefore it is impossible for the assembler to calculate the 
>   distance between them.  Since the symbols are local symbols they are 
> not emitted into the object file and so they are not available for the 
> linker to calculate the distance either.
> 
> The real root of the problem I believe is that you are using a broken 
> compiler.  You say that you are using GCC 2.3.2 which is an extremely 
> old version.  I would strongly urge you to upgrade to the 2.95 release, 
> or better yet the 3.4.4 release or even the 4.1 release.
> 
> If you cannot do this then see if the version of gcc you are using has 
> any switches to alter the way it handles case statements.  eg 
> -fno-jump-tables.
> 
> Cheers
>    Nick
> 

-- 
================================================================================
Ayonam Ray                                      Phone:  +91-80-51779962
SoftJin Technologies Pvt. Ltd.                  Fax:    +91-80-51157070
#102, Mobius Tower, SJR I-Park,                 E-mail: address@hidden
EPIP, Whitefield, Bangalore 560066              WWW:    www.softjin.com
INDIA
================================================================================






reply via email to

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