Relocation question (was: RE: Unsupported targets slated for removal)

Relocation question (was: RE: Unsupported targets slated for removal)

[Christian Groessler]

Hi,

> ----- Alan Modra wrote -----
> On Tue, Mar 22, 2005 at 06:08:30PM +0100, Christian Groessler wrote:
> > >     z8k-*-*           Christian, please update z8k to use bfd!
> >
> > Is there a guide how to do this somewhere, or should I simply start
> > defining BFD_ASSEMBLER and then fix what breaks...
>
> Yes, set bfd_gas=yes in configure.tgt, then fix what breaks.  Compare
> target object files before and after..

While doing this I've encountered the following problem. Consider this
source file:

                .text
                .long   INITFN
INITFN:         nop



If I compile it with the old assembler, I get the following relocation
entry in the object file:


/tmp/yyy.o:     file format coff-z8k

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
00000000 r_imm32           INITFN


If I compile it with my BFD_ASSEMBLER modified version, I get


/tmp/zzz.o:     file format coff-z8k

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
00000000 r_imm32           .text


Please note the different VALUEs.

If I compile the same source file with i386-coff-as, I get the same
result:


/tmp/333.o:     file format coff-i386

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
00000000 dir32             .text


Shouldn't the VALUE be INITFN, like in the old non-bfd assembler?

regards,
chris

RE: Relocation question (was: RE: Unsupported targets slated for removal)

[Dave Korn]

----Original Message----
>From: Christian Groessler
>Sent: 06 April 2005 11:24


> While doing this I've encountered the following problem. Consider this
> source file:
> 
>                 .text
>                 .long   INITFN
> INITFN:         nop

> If I compile it with the old assembler, I get the following relocation
> entry in the object file:

> RELOCATION RECORDS FOR [.text]:
> OFFSET   TYPE              VALUE
> 00000000 r_imm32           INITFN

> If I compile it with my BFD_ASSEMBLER modified version, I get

> RELOCATION RECORDS FOR [.text]:
> OFFSET   TYPE              VALUE
> 00000000 r_imm32           .text

> Please note the different VALUEs.

> Shouldn't the VALUE be INITFN, like in the old non-bfd assembler?


  This sounds like a REL-vs-RELA issue to me.  Perhaps the old assembler
produces a reloc with a value of 4, and places a zero in the .long at offset
0 in the .text section, while the new one produces a reloc with a value of
zero, and places the value 4 in the .long at offset 0 in the .text section?
You may need to switch the linker over if this is the case, or perhaps there
is an assumption in BFD_ASSEMBLER that the linker uses one format rather
than the other that isn't justified in this case?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Relocation question (was: RE: Unsupported targets slated for removal)

[Matt Thomas]

Christian Groessler wrote:
> Hi,
> 
> 
>>----- Alan Modra wrote -----
>>On Tue, Mar 22, 2005 at 06:08:30PM +0100, Christian Groessler wrote:
>>
>>>>    z8k-*-*           Christian, please update z8k to use bfd!
>>>
>>>Is there a guide how to do this somewhere, or should I simply start
>>>defining BFD_ASSEMBLER and then fix what breaks...
>>
>>Yes, set bfd_gas=yes in configure.tgt, then fix what breaks.  Compare
>>target object files before and after..
> 
> 
> While doing this I've encountered the following problem. Consider this
> source file:
> 
>                 .text
>                 .long   INITFN
> INITFN:         nop

INITFN does not seem to be a .globl symbol so it's not exported
from the object.

> Shouldn't the VALUE be INITFN, like in the old non-bfd assembler?

I don't think so.  Since INITFN is not global, the reloc can't
reference it.  So instead, the reloc uses .text+4; I'm assuming
that the assembler placed a value of 4 in the .long.

Does the reloc change if you add .globl INITFN ?
-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.

Re: Relocation question (was: RE: Unsupported targets slated for removal)

[Alan Modra]

On Wed, Apr 06, 2005 at 12:23:47PM +0200, Christian Groessler wrote:
> > ----- Alan Modra wrote -----
> > On Tue, Mar 22, 2005 at 06:08:30PM +0100, Christian Groessler wrote:
> > > >     z8k-*-*           Christian, please update z8k to use bfd!
> > >
> > > Is there a guide how to do this somewhere, or should I simply start
> > > defining BFD_ASSEMBLER and then fix what breaks...
> >
> > Yes, set bfd_gas=yes in configure.tgt, then fix what breaks.  Compare
> > target object files before and after..

Actually, I probably should have mentioned that the critical thing is
that after final linking you get the same result.

> While doing this I've encountered the following problem. Consider this
> source file:
> 
>                 .text
>                 .long   INITFN
> INITFN:         nop
> 
> 
> 
> If I compile it with the old assembler, I get the following relocation
> entry in the object file:
> 
> 
> /tmp/yyy.o:     file format coff-z8k
> 
> RELOCATION RECORDS FOR [.text]:
> OFFSET   TYPE              VALUE
> 00000000 r_imm32           INITFN
> 
> 
> If I compile it with my BFD_ASSEMBLER modified version, I get
> 
> 
> /tmp/zzz.o:     file format coff-z8k
> 
> RELOCATION RECORDS FOR [.text]:
> OFFSET   TYPE              VALUE
> 00000000 r_imm32           .text
> 
> 
> Please note the different VALUEs.

Either of these is likely OK.  In the second case, a reloc against a
local symbol INITFN is being reduced to a reloc against a section
symbol.  With larger assembly files this optimization can reduce the
size of the symbol table.  You can tweak which relocs may be reduced
with tc_fix_adjustable.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Relocation question (was: RE: Unsupported targets slated for removal)

[Alan Modra]

On Wed, Apr 06, 2005 at 11:40:30AM +0100, Dave Korn wrote:
>   This sounds like a REL-vs-RELA issue to me.  Perhaps the old assembler

No, it's simply an optimisation.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Relocation question (was: RE: Unsupported targets slated for removal)

[Alan Modra]

On Wed, Apr 06, 2005 at 04:10:43AM -0700, Matt Thomas wrote:
> I don't think so.  Since INITFN is not global, the reloc can't
> reference it.

Yes it can.  If a reloc references a local symbol, that symbol will be
emitted in the symbol table.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Relocation question (was: RE: Unsupported targets slated for removal)

[Christian Groessler]

On Wed, 6 Apr 2005, Alan Modra wrote:

> On Wed, Apr 06, 2005 at 12:23:47PM +0200, Christian Groessler wrote:
> >
> > Please note the different VALUEs.
>
> Either of these is likely OK.  In the second case, a reloc against a
> local symbol INITFN is being reduced to a reloc against a section
> symbol.  With larger assembly files this optimization can reduce the
> size of the symbol table.  You can tweak which relocs may be reduced
> with tc_fix_adjustable.

Thanks.
If I return 0 in tc_fix_adjustable the symbol name appears in the
relocation.

I find it more informative if the symbol name appears in the relocation,
but probaby other prefer the optimized version.
Makes it sense to make the tc_fix_adjustable return value user selectable?
Of course, only in cases where it doesn't matter technically.
I would implement a command line parameter to do this, and also modify the
other targets.

regards,
chris

Re: Relocation question (was: RE: Unsupported targets slated for removal)

[Ian Lance Taylor]

Christian Groessler <chris@groessler.org> writes:

> I find it more informative if the symbol name appears in the relocation,
> but probaby other prefer the optimized version.
> Makes it sense to make the tc_fix_adjustable return value user selectable?
> Of course, only in cases where it doesn't matter technically.
> I would implement a command line parameter to do this, and also modify the
> other targets.

I don't think that option would be particularly useful.  I can't
imagine why any ordinary user would ever want to set it, and I don't
see that it helps for debugging or anything.

Ian

Re: Relocation question (was: RE: Unsupported targets slated for removal)

[Alan Modra]

On Thu, Apr 07, 2005 at 04:41:27PM +0200, Christian Groessler wrote:
> I find it more informative if the symbol name appears in the relocation,
> but probaby other prefer the optimized version.

That's reasonable in the short term as you transition over to using
BFD_ASSEMBLER, particularly if you find bugs in your port related to
handling of relocs against section symbols.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre