converting SGL from COFF to ELF

RockinB

Established Member
It appears that files got different architectures(flags, HAS_*) after conversion(sh->sh4, 0x30->0x10, HAS_LOCALS->).

objcopy sets architecture from input file only, so no chance to do that manually.

Code:
sh-elf-objdump -f sglA00.o

sglA00.o: file format coff-sh

architecture: sh, flags 0x00000030:

HAS_SYMS, HAS_LOCALS

...

sh-elf-objcopy -Icoff-sh -Oelf32-sh sglA00.o

sh-elf-objdump -f sglA00.o

sglA00.o: file format elf32-sh

architecture: sh4, flags 0x00000010:

HAS_SYMS

...

I decided to take format elf32-sh because a file compiled with sh-elf-gcc -m2 got that format.

Is there any problem with that? I tried to link to the ELF version of SGL, but the linker reports unknown references...
 
I got the linking done with ELF.

The MAP file got a new section called .rodata.

Anyone knows what this is? It's only 8 Bytes long and starts at 0x54.

That's why my sl.bin is about 100 MB when I use objcopy.

I removed that section, but the binary didn't work in Satourne. So I gues I need to edit the link script to move the section elsewhere....
 
The elf binary produces an error when running in Saturnin and Satourne emulators.

I have no clue yet why the elf binary doesn't work, but the coff binary does.

Here is a file with binary, map and disassembly of the elf and coff version of SGL's DEMO_A:

[attachmentid=1259]

If anyone can give me a hint. I don't know much about the differences in a elf and coff toolchain.
 

Attachments

  • sgl_demo_a_coff_elf.rar
    29.4 KB · Views: 142
  • sgl_demo_a_coff_elf.rar
    29.4 KB · Views: 144
I guess it's the ELF version of SGL which makes the DEMO_A binary crash. But I won't verify that by compiling a SBL example now.

(vbt, did you use SGL startup code in your SBL apps?)

Aother conversion option:

Anyone thought of re-assembling the SGL? If as can optimize, we could possibly speed it up. Problem is just to generate asm from object files with objdump, which would need some AWK preprocessing...

(well, I've tried that on a simple file by hand)

Anyways, I'll focus on COFF for now.

Now I'm looking for some good tutorials.

Any suggestions?

Question:

How to do DOS commands like copy, move in a makefile

(unix mode)?
 
Originally posted by Rockin'-B@Thu, 2005-05-12 @ 12:10 PM

I guess it's the ELF version of SGL which makes the DEMO_A binary crash. But I won't verify that by compiling a SBL example now.

(vbt, did you use SGL startup code in your SBL apps?)


Not at all, I rebuilt and corrected everything needed to boot a SBL sample. I thought you had already manage to do this task. I found that not so easy, I could give you the objects needed to start a SBL app (strt_g.o or something like that)
 
I don't know offhand what the problem is, but converting unlinked objects is even less guaranteed to work than fully linked ones. I wouldn't worry about the different flags, AFAIK the HAS_LOCALS flag is COFF-specific. There is no problem with the files being marked as "sh4", . The main use is to differentiate the files from the 64-bit sh5.

The ".rodata" section is defined in the ELF specification, and is intended for read-only data. As you noticed, sections not assigned a location in your link script will be placed starting at location zero. What script did you use?

Copying files etc. in your makefiles is done just like compiling. Make doesn't care about what commands it's generating.
 
Originally posted by vbt+Thu, 2005-05-12 @ 07:40 PM--><div class='quotetop'>QUOTE(vbt @ Thu, 2005-05-12 @ 07:40 PM)</div><div class='quotemain'>Not at all, I rebuilt and corrected everything needed to boot a SBL sample. I thought you had already manage to do this task. I found that not so easy, I could give you the objects needed to start a SBL app (strt_g.o or something like that)

[post=133953]Quoted post[/post]​

[/b]


It's the first time I really tried to deal with SBL.

Do you know the difference between:

strt1_g.src, strt1_h.src

strt2_g.c strt2_h.c

<!--QuoteBegin-antime
@Thu, 2005-05-12 @ 09:30 PM

I don't know offhand what the problem is, but converting unlinked objects is even less guaranteed to work than fully linked ones. I wouldn't worry about the different flags, AFAIK the HAS_LOCALS flag is COFF-specific. There is no problem with the files being marked as "sh4", . The main use is to differentiate the files from the 64-bit sh5.

The ".rodata" section is defined in the ELF specification, and is intended for read-only data. As you noticed, sections not assigned a location in your link script will be placed starting at location zero. What script did you use?

Copying files etc. in your makefiles is done just like compiling. Make doesn't care about what commands it's generating.

[post=133956]Quoted post[/post]​

[/quote]

Ah, thanks.

I've just added the .rodata section to the linkscript between SLSTART and .text.

What's exactly meant by unlinked objects?

Well, I've included both ELF and COFF versions above.

I can't find what's causing the crash in Saturnin by myself.

This will take some time to figure out, maybe I will try a simple SBL example first.

Make just complains:

make.exe: copy:Command not found

I guess make runs in sh.exe.

Couldn't find a copy command in sh.exe --help

Doesn't work. Maybe I try putting a batch file into the binary folder.

edit: I could workaround that problem

but strange:

if using unix mode, it doesn't find DOS commands, but mkisofs,

if using win32 mode, it does find DOS commands, but not mkisofs
 
Originally posted by Rockin'-B@Fri, 2005-05-13 @ 10:46 AM

It's the first time I really tried to deal with SBL.

Do you know the difference between:

strt1_g.src, strt1_h.src

strt2_g.c strt2_h.c


I know I use only strt1_g.o and strt2_g.o . On a previous topic (not sure), il was supposed that H meant Hitachi and G for GCC.

.src were renamed .s and assembled with GASM even if I still have a ASMSH.EXE in my folder.
 
bump this old topic, is there a working elf sgl lib somewhere ?
slinitsystem fails

at start addr there is also a small difference :

upload_2019-5-7_14-7-6.png
 
Last edited:
it seems it looses PC address, any idea ?

if i compare elf VS coff it gives only one difference :

upload_2019-5-8_19-2-12.png


The working code is on the right.

Code:
L:\saturn\dev\CHROME2\sglIc0.o:     file format elf32-sh
architecture: sh, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000

Contents of section .text:
0000 2f862f96 2fa62fb6 2fc62fd6 4f226843  /./././././.O"hC
0010 6c536963 dd304d0b e40fdb30 e1002b10  lSic.0M....0..+.
0020 d12fe31f 28396083 40096112 c9013100  ./..(9`.@.a...1.
0030 8903d12c 6112410b 6403d12b 410b0009  ...,a.A.d..+A...
0040 da2ae500 4a0be40b d129410b 0009d129  .*..J....)A....)
0050 410b0009 d028400b 6483d128 d3282132  A....(@.d..(.(!2
0060 659ed028 400b6483 d02765c3 400b6483  e..(@.d..'e.@.d.
0070 d126e3ff 2131d126 6112d426 410b0009  .&..!1.&a..&A...
0080 d1259428 6112410b e500d224 e1052210  .%.(a.A....$..".
0090 69b0e17f e4002199 4d0b2b10 d120410b  i.....!.M.+.. A.
00a0 0009e500 4a0be40d d81e480b 0009e500  ....J.....H.....
00b0 4a0be40e 480b0009 480b0009 e1802919  J...H...H.....).
00c0 61b0219b 2b104f26 6df66cf6 6bf66af6  a.!.+.O&m.l.k.j.
00d0 69f6000b 68f6f17c 00000000 00000000  i...h..|........
00e0 06000324 06000320 00000000 00000000  ...$... ........
00f0 00000000 00000000 00000000 00000000  ................
0100 00000000 00000000 00000000 21000000  ............!...
0110 06000280 00000128 06000344 00000000  .......(...D....
0120 00000000 00000000                    ........      
Contents of section .data:
0128 0000e1fb 0000e1fa 0000ffff 0000e1f8  ................
0138 0000e1f0 0000e1e0 0000e1c0 0000e180  ................
0148 0000e100 0000fffb 0000fdfb 0000f9fb  ................
0158 0000f1fb 0000e000 0000ffff 0000ffff  ................
0168 0070ffff 0070ffff 0070ffff 0070ffff  .p...p...p...p..
0178 0070ffff 0070ffff 0070ffff 0070ffff  .p...p...p...p..
0188 0070ffff 0070ffff 0070ffff 0070ffff  .p...p...p...p..
0198 0070ffff 0070ffff 0070ffff 0070ffff  .p...p...p...p..

Disassembly of section .text:

00000000 <_slInitSystem>:
   0:    2f 86           mov.l    r8,@-r15
   2:    2f 96           mov.l    r9,@-r15
   4:    2f a6           mov.l    r10,@-r15
   6:    2f b6           mov.l    r11,@-r15
   8:    2f c6           mov.l    r12,@-r15
   a:    2f d6           mov.l    r13,@-r15
   c:    4f 22           sts.l    pr,@-r15
   e:    68 43           mov    r4,r8
  10:    6c 53           mov    r5,r12
  12:    69 63           mov    r6,r9
  14:    dd 30           mov.l    d8 <_slInitSystem+0xd8>,r13    ! 0 <_slInitSystem>
  16:    4d 0b           jsr    @r13
  18:    e4 0f           mov    #15,r4
  1a:    db 30           mov.l    dc <_slInitSystem+0xdc>,r11    ! 0 <_slInitSystem>
  1c:    e1 00           mov    #0,r1
  1e:    2b 10           mov.b    r1,@r11
  20:    d1 2f           mov.l    e0 <_slInitSystem+0xe0>,r1    ! 6000324
  22:    e3 1f           mov    #31,r3
  24:    28 39           and    r3,r8
  26:    60 83           mov    r8,r0
  28:    40 09           shlr2    r0
  2a:    61 12           mov.l    @r1,r1
  2c:    c9 01           and    #1,r0
  2e:    31 00           cmp/eq    r0,r1
  30:    89 03           bt    3a <_slInitSystem+0x3a>
  32:    d1 2c           mov.l    e4 <_slInitSystem+0xe4>,r1    ! 6000320
  34:    61 12           mov.l    @r1,r1
  36:    41 0b           jsr    @r1
  38:    64 03           mov    r0,r4
  3a:    d1 2b           mov.l    e8 <_slInitSystem+0xe8>,r1    ! 0 <_slInitSystem>
  3c:    41 0b           jsr    @r1
  3e:    00 09           nop 
  40:    da 2a           mov.l    ec <_slInitSystem+0xec>,r10    ! 0 <_slInitSystem>
  42:    e5 00           mov    #0,r5
  44:    4a 0b           jsr    @r10
  46:    e4 0b           mov    #11,r4
  48:    d1 29           mov.l    f0 <_slInitSystem+0xf0>,r1    ! 0 <_slInitSystem>
  4a:    41 0b           jsr    @r1
  4c:    00 09           nop 
  4e:    d1 29           mov.l    f4 <_slInitSystem+0xf4>,r1    ! 0 <_slInitSystem>
  50:    41 0b           jsr    @r1
  52:    00 09           nop 
  54:    d0 28           mov.l    f8 <_slInitSystem+0xf8>,r0    ! 0 <_slInitSystem>
  56:    40 0b           jsr    @r0
  58:    64 83           mov    r8,r4
  5a:    d1 28           mov.l    fc <_slInitSystem+0xfc>,r1    ! 0 <_slInitSystem>
  5c:    d3 28           mov.l    100 <_slInitSystem+0x100>,r3    ! 0 <_slInitSystem>
  5e:    21 32           mov.l    r3,@r1
  60:    65 9e           exts.b    r9,r5
  62:    d0 28           mov.l    104 <_slInitSystem+0x104>,r0    ! 0 <_slInitSystem>
  64:    40 0b           jsr    @r0
  66:    64 83           mov    r8,r4
  68:    d0 27           mov.l    108 <_slInitSystem+0x108>,r0    ! 0 <_slInitSystem>
  6a:    65 c3           mov    r12,r5
  6c:    40 0b           jsr    @r0
  6e:    64 83           mov    r8,r4
  70:    d1 26           mov.l    10c <_slInitSystem+0x10c>,r1    ! 21000000
  72:    e3 ff           mov    #-1,r3
  74:    21 31           mov.w    r3,@r1
  76:    d1 26           mov.l    110 <_slInitSystem+0x110>,r1    ! 6000280
  78:    61 12           mov.l    @r1,r1
  7a:    d4 26           mov.l    114 <_slInitSystem+0x114>,r4    ! 128 <_IntPrioMask>
  7c:    41 0b           jsr    @r1
  7e:    00 09           nop 
  80:    d1 25           mov.l    118 <_slInitSystem+0x118>,r1    ! 6000344
  82:    94 28           mov.w    d6 <_slInitSystem+0xd6>,r4    ! f17c
  84:    61 12           mov.l    @r1,r1
  86:    41 0b           jsr    @r1
  88:    e5 00           mov    #0,r5
  8a:    d2 24           mov.l    11c <_slInitSystem+0x11c>,r2    ! 0 <_slInitSystem>
  8c:    e1 05           mov    #5,r1
  8e:    22 10           mov.b    r1,@r2
  90:    69 b0           mov.b    @r11,r9
  92:    e1 7f           mov    #127,r1
  94:    e4 00           mov    #0,r4
  96:    21 99           and    r9,r1
  98:    4d 0b           jsr    @r13
  9a:    2b 10           mov.b    r1,@r11
  9c:    d1 20           mov.l    120 <_slInitSystem+0x120>,r1    ! 0 <_slInitSystem>
  9e:    41 0b           jsr    @r1
  a0:    00 09           nop 
  a2:    e5 00           mov    #0,r5
  a4:    4a 0b           jsr    @r10
  a6:    e4 0d           mov    #13,r4
  a8:    d8 1e           mov.l    124 <_slInitSystem+0x124>,r8    ! 0 <_slInitSystem>
  aa:    48 0b           jsr    @r8
  ac:    00 09           nop 
  ae:    e5 00           mov    #0,r5
  b0:    4a 0b           jsr    @r10
  b2:    e4 0e           mov    #14,r4
  b4:    48 0b           jsr    @r8
  b6:    00 09           nop 
  b8:    48 0b           jsr    @r8
  ba:    00 09           nop 
  bc:    e1 80           mov    #-128,r1
  be:    29 19           and    r1,r9
  c0:    61 b0           mov.b    @r11,r1
  c2:    21 9b           or    r9,r1
  c4:    2b 10           mov.b    r1,@r11
  c6:    4f 26           lds.l    @r15+,pr
  c8:    6d f6           mov.l    @r15+,r13
  ca:    6c f6           mov.l    @r15+,r12
  cc:    6b f6           mov.l    @r15+,r11
  ce:    6a f6           mov.l    @r15+,r10
  d0:    69 f6           mov.l    @r15+,r9
  d2:    00 0b           rts 
  d4:    68 f6           mov.l    @r15+,r8
  d6:    f1 7c           .word 0xf17c
    ...
  e0:    06 00           .word 0x0600
  e2:    03 24           mov.b    r2,@(r0,r3)
  e4:    06 00           .word 0x0600
  e6:    03 20           .word 0x0320
    ...
10c:    21 00           mov.b    r0,@r1
10e:    00 00           .word 0x0000
110:    06 00           .word 0x0600
112:    02 80           .word 0x0280
114:    00 00           .word 0x0000
116:    01 28           .word 0x0128
118:    06 00           .word 0x0600
11a:    03 44           mov.b    r4,@(r0,r3)
    ...
 
Last edited:
it's not perfect but the issue happens on slInitSystem
first action is it restores r8 to r14 using the stack
upload_2019-5-12_3-23-7.png

i did a manual step by step
upload_2019-5-12_3-27-47.png
 
here are the little secrets :
remove "-Xlinker --format=coff-sh" from the makefile (ld flags)
add in the header of the linker script :
OUTPUT_FORMAT(coff-sh)
use only libs converted to elf
 
Wow, I'm deeply thankful for this thread. Was banging my head against the wall on this. I also had isolated the issue to slinitsystem() but couldn't figure out what the issue was. Randomly, some demos would compile fine and work prior to the linker script change noted above, specifically if the debug library was included in code. So bizarre. Thanks for this!!!
 
Wow, I'm deeply thankful for this thread. Was banging my head against the wall on this. I also had isolated the issue to slinitsystem() but couldn't figure out what the issue was. Randomly, some demos would compile fine and work prior to the linker script change noted above, specifically if the debug library was included in code. So bizarre. Thanks for this!!!
some relocations are bad and slinitsystem loops, there is a way to fix the lib but it's not easy
 
some relocations are bad and slinitsystem loops, there is a way to fix the lib but it's not easy
What are your initial thoughts on that? I'd love to understand any theories behind this. I tried multiple GNU SH compilers too just to ensure it wasn't a compiler issue.
 
Back
Top