#1804 --no-std-crt0 linking problem on -mz80

open
nobody
linker (61)
5
2014-01-06
2011-07-10
stewartjk
No

Compiler versions tried are 3.0.0 and latest snapshot.

When I use the --no-std-crt0 option in a -mz80 build and supply my own crt0.rel file linking does not appear to be working correctly even when the crt0.rel file is a copy of the original z80 crt0.rel. The problem I see is the call to initialise the data array points to the C9 return code after the array initialisation code. In the attachment I have provided some simple test code and the good and bad binary images of the code produced.

To work around the problem I have to remove the --no-std-crt0 option and copy my customised crt0.rel file to the /usr/local/share/sdcc/lib/z80/ directory.

Problem build:
sdcc -mz80 --no-std-crt0 --data-loc 0 testcrt0.rel crt0.rel

Build that works
sdcc -mz80 --data-loc 0 testcrt0.rel

I'm new to sdcc so apologies if I'm doing something incorrect.

Discussion

1 2 > >> (Page 1 of 2)
  • stewartjk
    stewartjk
    2011-07-10

    source and binary image

     
    Attachments
  • The workaround probably just changes the order, in which the linker sees the files.
    Try setting --data-loc and --code-loc to more sensible values. In particular, do not tell the linker to place the any of those sections at the same place as the crt0.

    Your example tells the linker to place both the data and part of crt0 at address zero (the crt0 has an .org 0 and .org 0x100). The safe way is probaly to try rather high --data-loc and --code-loc first, and then reduce it to calim back unused space between crt0 and them.

    Please report back if this fixes your problem.

    Philipp

     
  • stewartjk
    stewartjk
    2011-07-10

    I've tried all sorts of settings with code and data locations, here is one with some settings that seem sensible to me but still produces the same problem:

    sdcc -mz80 --no-std-crt0 --code-loc 0x0800 --data-loc 0x1000 testcrt0.rel crt0.rel

    The code goes into 0x0800 fine but the data initialisation still wants to call the 0xC9 return instruction at 0x1024. It should actually be calling 0x100d instead.

    00000100 31 FF FF CD 24 10 CD 00 08 C3 0D 08

    00001000 FF FF FF FF FF FF FF FF 21 00 10 36 12 21 01 10 36 12 23 36 12 23 36 12 23 36 12 23 36 12 23 36
    00001020 12 23 36 12 C9

    It would appear that the --no-std-crt0 option insists that you have to init the data yourself but this is not what the manual states, I just want to tell the compiler to use my own crt0.rel file and it should not be bypassing the initialisation of the data.

     
  • stewartjk
    stewartjk
    2011-07-10

    I've tried all sorts of settings with code and data locations, here is one with some settings that seem sensible to me but still produces the same problem:

    sdcc -mz80 --no-std-crt0 --code-loc 0x0800 --data-loc 0x1000 testcrt0.rel crt0.rel

    The code goes into 0x0800 fine but the data initialisation still wants to call the 0xC9 return instruction at 0x1024. It should actually be calling 0x100d instead.

    00000100 31 FF FF CD 24 10 CD 00 08 C3 0D 08

    00001000 FF FF FF FF FF FF FF FF 21 00 10 36 12 21 01 10 36 12 23 36 12 23 36 12 23 36 12 23 36 12 23 36
    00001020 12 23 36 12 C9

    It would appear that the --no-std-crt0 option insists that you have to init the data yourself but this is not what the manual states, I just want to tell the compiler to use my own crt0.rel file and it should not be bypassing the initialisation of the data.

     
    • labels: 355281 --> 410691
     
  • Could you try

    1) Swapping the order of testcrt0.rel and crt0.rel in your command line
    2) Using a higher value for --code-loc than for --data-loc
    3) Both of the above

    And provide the .map files?

    Currently this looks like a bug in the default crt0 to me:
    .area _GSINIT
    gsinit::
    .area _GSFINAL
    ret

    will only work if the linker sees the crt0 first, placing the gsinit:: at the start of the gsinit section, and the initialization from the other files after that, before the ret. If the linker sees the other filees first, it will first place the initialization ocde, effectively jumping to the ret at the end of the initialization.

    Philipp

     
  • stewartjk
    stewartjk
    2011-07-10

    • labels: 410691 --> linker
     
  • stewartjk
    stewartjk
    2011-07-10

    Apologies for the double post before...

    Also I meant to say:

    "The code goes into 0x0800 fine but the data initialisation still wants to
    call the 0xC9 return instruction at 0x1008."

     
  • stewartjk
    stewartjk
    2011-07-10

    As can be seen the code and data locations don't change even when swapping the addresses...

    Swapped rel ordering:
    sdcc -mz80 --no-std-crt0 --code-loc 0x0800 --data-loc 0x1000 crt0.rel testcrt0.rel
    00000100 31 FF FF CD 24 08 CD 00 10 C3 0D 10
    00000800 FF FF FF FF FF FF FF FF 21 00 08 36 12 21 01 08 36 12 23 36 12 23 36 12 23 36 12 23 36 12 23 36
    00000820 12 23 36 12 C9
    00001000 3E 30 F5 33 CD 13 10 33 C9 3E 02 CF C9 3E 00 CF 76 18 FD 21 02 00 39 6E 3E 01 CF C9 6B 3E 01 CF
    00001020 C9

    Swapped rel ordering address locations:
    sdcc -mz80 --no-std-crt0 --code-loc 0x1000 --data-loc 0x0800 crt0.rel testcrt0.rel
    00000100 31 FF FF CD 24 08 CD 00 10 C3 0D 10
    00000800 FF FF FF FF FF FF FF FF 21 00 08 36 12 21 01 08 36 12 23 36 12 23 36 12 23 36 12 23 36 12 23 36
    00000820 12 23 36 12 C9
    00001000 3E 30 F5 33 CD 13 10 33 C9 3E 02 CF C9 3E 00 CF 76 18 FD 21 02 00 39 6E 3E 01 CF C9 6B 3E 01 CF
    00001020 C9

    Normal rel ordering and swapped address locations:
    sdcc -mz80 --no-std-crt0 --code-loc 0x1000 --data-loc 0x0800 testcrt0.rel crt0.rel
    00000100 31 FF FF CD 24 08 CD 00 10 C3 0D 10
    00000800 FF FF FF FF FF FF FF FF 21 00 08 36 12 21 01 08 36 12 23 36 12 23 36 12 23 36 12 23 36 12 23 36
    00000820 12 23 36 12 C9
    00001000 3E 30 F5 33 CD 13 10 33 C9 3E 02 CF C9 3E 00 CF 76 18 FD 21 02 00 39 6E 3E 01 CF C9 6B 3E 01 CF
    00001020 C9

     
  • stewartjk
    stewartjk
    2011-07-10

    map file

     
    Attachments
1 2 > >> (Page 1 of 2)