[uClinux-dev] elf2flt porting questions

D. Jeff Dionne jeff at ArcturusNetworks.com
Tue Mar 4 09:13:34 EST 2003

On Tuesday, March 4, 2003, at 02:24 AM, Greg Ungerer wrote:

> Hi Matt,
> Matt Waddel wrote:
>> I am trying to port the elf2flt code to a new architecure
>> and I have some questions.
>> 1) Are uClinux relocations limited to 4 bytes by the
>> operating system?
> No. That is just the most common size by far.
> This is very much architecture dependant.

There is likely a difference between the size BFD uses to
store the relocation in it's data structures and the size of
the relocation itself.  For instance, on SPARC there are
relocations which are 30 bits (you can't have an instruction
on anything but a long boundary anyway, so...).  But BFD
has to use 4 bytes for them so this test passes.

>>  The following statement emits an error
>> when a 2 byte relocation is encountered, but 2 byte
>> relocations are used in the blackfin processor. (R_huimm16
>> and R_luimm16)  Is it ok to allow a sym_reloc_size of 2?
>>    /* Calculate the sym address ourselves.  */
>>    sym_reloc_size = bfd_get_reloc_size(q->howto);
>>    if (sym_reloc_size != 4) {
>>        printf("ERROR: bad reloc size=%d for symbol=%s\n",
>>                sym_reloc_size, sym_name);
>>        rc = -1;
>>        continue;
>>        }
> Ahh, I see. Looking at this I think this is a throw back
> to the original m68k elf2flt. I don't think this check
> should be done for all architectures...

Could be even before that, back to obj-res for the Palm Pilot,
but who knows.  I can't see any need for this really because the
type is checked per architecture since you need multiple strategies
for (many of) the types of reloc emitted.  Watch out for relocations
split across multiple instructions... gcc has a habit of reordering them
in the instruction stream and it can be a pain.  If you have 16 bit
relocations, you may have a simmilar problem on BlackFIN (with
the other half of the reloc'd address), otherwise it might be a
relative offset.  In any case, a 16 bit offset will require you to come
up with a strategy to deal with it which is different than anything
that is there I would think.  Note that elf2flt and binfmt_flat in the
kernel are very interdepandant, you need to work on both at the
same time.

>> 2) Since there has been a some activity recently on the
>> uClinux mailing list about the elf2flt conversion, how is
>> the best way to determine if this is working correctly in
>> a new system?  Any troubleshooting tips would be
>> appreciated.
> Start small :-)
> I would suggest constructing some very simple test cases.
> A single system call (write is a good one) for example.
> You pretty much need to manually check that your relocation
> is being performed as expected.

Yes, in every possible case.  There can be more too, if your gcc
emits instructions which make an assumption that can't be relocated.
Generally speaking, this is more (or perhaps only) a problem when
trying to use XIP instead of load time relocations.

> Make sure you check relocatable values inside instructions too,
> if your architecture does that. The sparc support in elf2flt
> and linux-2.0.x/binfmt_flat.c is an example of this.

It's a RISCy thing ;^)  Ugly, really.  Gotta love those 32 bit
fixed length instructions with 22bit/10bit split relocs...

>> 3) I get errors and the build dies during the creation of
>> the .gdb file.  I have commented out the .gdb file creation,
>> but could this be repaired by adding the stabs sections to
>> the linker script?
> Hmm, I would not have thought so. What are the errors?

Make sure you understand how the multiple passes through
ld are used, or it will be impossible to calculate the right relocation
values!  A fully relocatable link (ld -r) throws away information,
for instance.


> Regards
> Greg
> ----------------------------------------------------------------------- 
> -
> Greg Ungerer  --  Chief Software Wizard        EMAIL:   
> gerg at snapgear.com
> SnapGear Pty Ltd                               PHONE:    +61 7 3435  
> 2888
> 825 Stanley St,                                  FAX:    +61 7 3891  
> 3630
> Woolloongabba, QLD, 4102, Australia              WEB:    
> www.SnapGear.com
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

More information about the uClinux-dev mailing list