This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: m68k reloc types


Hi,

On Mon, 16 Aug 2004, Andreas Schwab wrote:

> Roman Zippel <zippel@linux-m68k.org> writes:
> 
> > One issue that really confused me at first is that some m68k pic reloc 
> > types do something completely different than their i386 counterparts.
> 
> The m68k has different capabilites than the i386.

The capabilities are actually quite similiar, i386 has no direct pc 
relative addressing mode, but the trick used has the same effect from the 
linker pointer of view. What different kind of capabilities do you have in 
mind?

> > Here an example:
> >
> > 0000003e <f>:
> >   3e:   4e56 0000       linkw %fp,#0
> >   42:   2f0d            movel %a5,%sp@-
> >   44:   4bfb 0170 0000  lea %pc@(46 <f+0x8>),%a5
> >   4a:   0000 
> >                         48: R_68K_GOT32 _GLOBAL_OFFSET_TABLE_+0x2
> >   4c:   2075 0170 0000  moveal %a5@(00000000),%a0
> >   52:   0000 
> >                         50: R_68K_GOT32O        x
> >   54:   2010            movel %a0@,%d0
> >   56:   2a5f            moveal %sp@+,%a5
> >   58:   4e5e            unlk %fp
> >   5a:   4e75            rts
> >
> > i386 uses R_386_GOTPC and R_386_GOT32 here
> 
> Which are basically the same as R_68K_GOT32 and R_68K_GOT32O, resp.

That R_68K_GOT32O is the same as R_386_GOT32 is not a little confusing? 
What should we call R_386_GOTOFF if we wanted to implement it for the m68k 
linker?

> > AFAICS it should be possible to fix this, existing binaries may not break 
> > of course, but I think it should be possible to just rename this 
> > within binutils.
> 
> Why do you need to rename them?  The names are defined by the ELF specs.

Which I don't have access to. A quote of relevant parts would be helpful 
(especially the difference between R_68K_GOT32 and R_68K_GOT32O).

> > Does anyone sees a problem with fixing this or does someone even know the 
> > reason for these anomalies?
> 
> I see nothing broken here.

Could you please explain the rationale behind the _GLOBAL_OFFSET_TABLE_ 
checks in elf32-m68k.c? Unfortunately the cvs history doesn't go that far.

bye, Roman


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]