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

[Paul M. <le...@li...>]

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:

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.


> 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.

> > 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.

Regards,

-- 
Paul Mundt <le...@li...>