Re: [uClinux-dev] Re: [linuxsh-dev] init problems on MMU-less SH-4

[David M. <da...@sn...>]

Jivin Paul Mundt lays it down ...
> On Mon, 2003-01-06 at 17:06, David McCullough wrote:
> > Ok,  I guess it's a possibility that on SH you can generate an executable
> > that doesn't need relocations,  but I would be suspicious,  especially if
> > it isn't built with PIC.  It sounds like elf2flt is not being used
> > correctly as all the SH code I have seen generated would need relocations
> > to run on a non-MMU system.
> > 
> I don't think its a matter of elf2flt not being used correctly, since I
> can use a cross-compiled read-elf to look at the ELF and it also reports
> this. Ie:


elf2flt is not run on the final executable file.  Executable files for the
most part do not have relocations,  they are all resolved during the link
stage.

elf2flt runs on a relocatable version of the executable (not quite fully
linked) so that it can find all the parts of the program that will actually
need relocating in a non-MMU environment.  The ld-elf2flt script that comes
with elf2flt is generally used to replace the linker so it can intercept
the -elf2flt flag on the link line and take the appropriate actions on the
files as required.  The linker is renamed ld.real and ld-elf2flt calls this.

I am not 100% on how this is handled by the uClibc cross tools.  I think
ld-elf2flt has been moved into 'C' code somewhere.


> ELF Header:
>   Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
>   Class:                             ELF32
>   Data:                              2's complement, little endian
>   Version:                           1 (current)
>   OS/ABI:                            UNIX - System V
>   ABI Version:                       0
>   Type:                              EXEC (Executable file)
>   Machine:                           Hitachi SH
>   Version:                           0x1
>   Entry point address:               0x4000c0
>   Start of program headers:          52 (bytes into file)
>   Start of section headers:          246920 (bytes into file)
>   Flags:                             0x9
>   Size of this header:               52 (bytes)
>   Size of program headers:           32 (bytes)
>   Number of program headers:         2
>   Size of section headers:           40 (bytes)
>   Number of section headers:         14
>   Section header string table index: 13
> 
> Section Headers:
>   [Nr] Name              Type            Addr     Off    Size   ES Flg
> Lk Inf Al
>   [ 0]                   NULL            00000000 000000 000000 00     
> 0   0  0
>   [ 1] .init             PROGBITS        00400074 000074 00003c 00  AX 
> 0   0  4
>   [ 2] .text             PROGBITS        004000c0 0000c0 031260 00  AX 
> 0   0 32
>   [ 3] .fini             PROGBITS        00431320 031320 000030 00  AX 
> 0   0  4
>   [ 4] .rodata           PROGBITS        00431350 031350 00a2e4 00   A 
> 0   0  4
>   [ 5] .data             PROGBITS        0044b634 03b634 000a10 00  WA 
> 0   0  4
>   [ 6] .eh_frame         PROGBITS        0044c044 03c044 000004 00  WA 
> 0   0  4
>   [ 7] .ctors            PROGBITS        0044c048 03c048 000008 00  WA 
> 0   0  4
>   [ 8] .dtors            PROGBITS        0044c050 03c050 000008 00  WA 
> 0   0  4
>   [ 9] .jcr              PROGBITS        0044c058 03c058 000004 00  WA 
> 0   0  4
>   [10] .got              PROGBITS        0044c05c 03c05c 0003d4 04  WA 
> 0   0  4
>   [11] .sbss             PROGBITS        0044c430 03c430 000000 00   W 
> 0   0  1
>   [12] .bss              NOBITS          0044c430 03c430 00482c 00  WA 
> 0   0  4
>   [13] .shstrtab         STRTAB          00000000 03c430 000058 00     
> 0   0  1
> Key to Flags:
>   W (write), A (alloc), X (execute), M (merge), S (strings)
>   I (info), L (link order), G (group), x (unknown)
>   O (extra OS processing required) o (OS specific), p (processor
> specific)
> 
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg
> Align
>   LOAD           0x000000 0x00400000 0x00400000 0x3b634 0x3b634 R E
> 0x10000
>   LOAD           0x03b634 0x0044b634 0x0044b634 0x00dfc 0x05628 RW 
> 0x10000
> 
>  Section to Segment mapping:
>   Segment Sections...
>    00     .init .text .fini .rodata 
>    01     .data .eh_frame .ctors .dtors .jcr .got .bss 
> 
> There is no dynamic segment in this file.
> 
> There are no relocations in this file.
> 
> There are no unwind sections in this file.
> 
> No version information found in this file.
> 
> That's just limited to this particular application. If I look at another
> SH bin, there's quite a bit of relocation, but that's mostly limited to
> R_SH_COPY, R_SH_JMP_SLOT and R_SH_GLOB_DAT.

All of the above looks like information from the final executable for the
file.

You need to try and get you hands on the temporary file that ld-elf2flt (or
it's equivalent) creates.  It is called XXX.elf and if it doesn't have any
relocations then you do indeed have a file with no relocations.


> > binfmt_elf will deal with it,  but the program will not run.  You would
> > have to link every application at a different address and then make sure
> > that you never ran more than one instance of each.  Even then I doubt it
> > would work.  You will need to use flat executables to get it going.
>
> Okay, so by this assumption, elf2flt should _still_ convert the bin even
> if there aren't any relocations to speak of? In that case, its current
> behavior is broken.


I'm still not convinced but,  if you don't need relocations for SH then
remove the test for SH platforms.  This check is merely a safety check as
on all the platforms currently supported, the absence of relocations
signals broken apps or incorrect use of elf2flt.  This was of more
importance in the past when developers used to run elf2flt by hand
and often got it wrong ;-)


You can double check the need for relocations by looking at the output of
sh-linux-objdump -D XX.elf.  It will be obvious from the asm if it actually
needs relocations.  There will be absolute addresses in the code.  Any
absolute address used for a branch, function call or data access will
need a relocation in the flat file to work in a non-MMU environment.


> > > Currently I have R_SH_DIR32, R_SH_REL32, R_SH_GOT32 and R_SH_GOTPC
> > > supported. I'll submit patches for this once the above mess is worked
> > > out.
> > 
> > Sounds good.
> > 
> > By the way,  I subscribed to linuxsh-dev a month or so ago and haven't seen
> > any traffic.  It is working or am I missing something ?
>
> This is a dangerous combination of SourceForge thinking and there being
> low traffic in general. Though if you're seeing this mail and the one
> before it, you're likely seeing traffic from there, since uclinux-dev
> doesn't seem to like me sending it mail.
> 
> I have still to convince mailman on SF that I can send it mail, being
> subscribed and all... SF idiocies (to which there is an incredible
> abundance) usually work themselves out given some time.
> 
> You may also wish to look at the list archives (if they're working yet,
> see note about SF idiocies in preceding paragraph) to see if there's
> anything you've missed.

Ok,  it suddenly seems to be working.  I received two copies of my last
reply,  but only one for the original message ??

uclinux-dev will not let you post unless you are subscribed IIRC,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
da...@sn...  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security