* Relocation question (was: RE: Unsupported targets slated for removal)
@ 2005-04-06 10:24 Christian Groessler
2005-04-06 10:40 ` Dave Korn
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Christian Groessler @ 2005-04-06 10:24 UTC (permalink / raw)
To: binutils; +Cc: chris
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Relocation question (was: RE: Unsupported targets slated for removal)
2005-04-06 10:24 Relocation question (was: RE: Unsupported targets slated for removal) Christian Groessler
@ 2005-04-06 10:40 ` Dave Korn
2005-04-06 12:49 ` Alan Modra
2005-04-06 11:10 ` Matt Thomas
2005-04-06 12:46 ` Alan Modra
2 siblings, 1 reply; 9+ messages in thread
From: Dave Korn @ 2005-04-06 10:40 UTC (permalink / raw)
To: 'Christian Groessler', binutils
----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....
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Relocation question (was: RE: Unsupported targets slated for removal)
2005-04-06 10:24 Relocation question (was: RE: Unsupported targets slated for removal) Christian Groessler
2005-04-06 10:40 ` Dave Korn
@ 2005-04-06 11:10 ` Matt Thomas
2005-04-06 12:50 ` Alan Modra
2005-04-06 12:46 ` Alan Modra
2 siblings, 1 reply; 9+ messages in thread
From: Matt Thomas @ 2005-04-06 11:10 UTC (permalink / raw)
To: Christian Groessler; +Cc: binutils
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Relocation question (was: RE: Unsupported targets slated for removal)
2005-04-06 10:24 Relocation question (was: RE: Unsupported targets slated for removal) Christian Groessler
2005-04-06 10:40 ` Dave Korn
2005-04-06 11:10 ` Matt Thomas
@ 2005-04-06 12:46 ` Alan Modra
2005-04-07 14:42 ` Christian Groessler
2 siblings, 1 reply; 9+ messages in thread
From: Alan Modra @ 2005-04-06 12:46 UTC (permalink / raw)
To: Christian Groessler; +Cc: binutils
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Relocation question (was: RE: Unsupported targets slated for removal)
2005-04-06 10:40 ` Dave Korn
@ 2005-04-06 12:49 ` Alan Modra
0 siblings, 0 replies; 9+ messages in thread
From: Alan Modra @ 2005-04-06 12:49 UTC (permalink / raw)
To: Dave Korn; +Cc: 'Christian Groessler', binutils
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Relocation question (was: RE: Unsupported targets slated for removal)
2005-04-06 11:10 ` Matt Thomas
@ 2005-04-06 12:50 ` Alan Modra
0 siblings, 0 replies; 9+ messages in thread
From: Alan Modra @ 2005-04-06 12:50 UTC (permalink / raw)
To: Matt Thomas; +Cc: Christian Groessler, binutils
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Relocation question (was: RE: Unsupported targets slated for removal)
2005-04-06 12:46 ` Alan Modra
@ 2005-04-07 14:42 ` Christian Groessler
2005-04-07 15:58 ` Ian Lance Taylor
2005-04-07 22:52 ` Alan Modra
0 siblings, 2 replies; 9+ messages in thread
From: Christian Groessler @ 2005-04-07 14:42 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Relocation question (was: RE: Unsupported targets slated for removal)
2005-04-07 14:42 ` Christian Groessler
@ 2005-04-07 15:58 ` Ian Lance Taylor
2005-04-07 22:52 ` Alan Modra
1 sibling, 0 replies; 9+ messages in thread
From: Ian Lance Taylor @ 2005-04-07 15:58 UTC (permalink / raw)
To: Christian Groessler; +Cc: binutils
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Relocation question (was: RE: Unsupported targets slated for removal)
2005-04-07 14:42 ` Christian Groessler
2005-04-07 15:58 ` Ian Lance Taylor
@ 2005-04-07 22:52 ` Alan Modra
1 sibling, 0 replies; 9+ messages in thread
From: Alan Modra @ 2005-04-07 22:52 UTC (permalink / raw)
To: Christian Groessler; +Cc: binutils
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2005-04-07 22:52 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-04-06 10:24 Relocation question (was: RE: Unsupported targets slated for removal) Christian Groessler
2005-04-06 10:40 ` Dave Korn
2005-04-06 12:49 ` Alan Modra
2005-04-06 11:10 ` Matt Thomas
2005-04-06 12:50 ` Alan Modra
2005-04-06 12:46 ` Alan Modra
2005-04-07 14:42 ` Christian Groessler
2005-04-07 15:58 ` Ian Lance Taylor
2005-04-07 22:52 ` Alan Modra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).