Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    emard
    @emard
    small C saxonsoc compiler would be great! QL then at least from ESP32 side should be easy, both images will be open and there won't be timing issues as both 1st and 2nd drive will never be transferring data at the same time this will not add more latency when SD must stream 2 files simultaneously.
    Paul Ruiz
    @pnru_gitlab

    @emard 'small' is relative. The cross compiler has >0.5MB of executable; that includes 4 backends (spare, mips, x86 and riscv32) but it will be >0.3MB for sure. Runtime memory use may be double that.

    @lawrie @emard I did look a bit more at the toolchain. Compiler, assembler, archiver all appear to work fine. The utils appear to have roots in the ECO32 project: https://github.com/hgeisse/eco32

    The riscv32 linker/loader seems to be a custom job. I managed to build a full libc.lib and could link a "hello world" program to an a.out file. That file is ~30KB, as it drags in much of stdio and of the floating point library routines.

    As there is no OS, the C library just has stubs for some of the sys calls (https://github.com/michg/riscv32_lcc/blob/master/lcc/bin/libs/stdlib/syscall.c), with I/O hardcoded to a UART.

    All in all, the compiler seems fine, but getting it to run on SaxonSoc is not a slam dunk.

    emard
    @emard
    @pnru_gitlab 0.3-1MB is small for 30MB RAM free. I also agree the best option is to ask original author for help about lcc on saxonsoc
    Lawrie Griffiths
    @lawrie
    I made a bit of progress on lcc. I can now run this on SaxonSoc Linux: lcc -Wo-lccdir=/lccbin -S -target=riscv32 hello.c -o hello.s and it produces the risc-v assembly file.
    The buildroot cross-compiler used to build Linux worked better than the others I tried. I can now build lcc by make lburg then make CC=cross-compiler all.
    Paul Ruiz
    @pnru_gitlab
    Great. Assembling that file to a .o object file should work as well.
    Lawrie Griffiths
    @lawrie
    If you do -o hello.o, you just get the sasembler in hello.o.
    I don't think lcc produces anything other than assembler output.
    I thought the assembler and loader from binutils was needed for that.
    Paul Ruiz
    @pnru_gitlab
    Yes, correct. Use -c instead of -s to get an object file. That will try to inboke the assembler at location ../../binutils/bin/as telative to the location of lcc itself.
    Lawrie Griffiths
    @lawrie
    root@buildroot:~# lcc -Wo-lccdir=/lccbin -target=riscv32 hello.c -o hello.o
    lcc: /lccbin/../../binutils/bin/as: No such file or directory
    Paul Ruiz
    @pnru_gitlab
    That binary can be compiled from the binutils/as dir in the repo
    Paul Ruiz
    @pnru_gitlab
    You may want to edit https://github.com/michg/riscv32_lcc/blob/master/lcc/etc/linux.c when building lcc to get a bit more sanity in the paths.
    Lawrie Griffiths
    @lawrie
    root@buildroot:~# lcc -Wo-lccdir=/riscv32_lcc/lcc/bin -target=riscv32 hello.c -o
     hello.o
    Assembling module '/tmp/lcc1711.s'...
    lcc: /riscv32_lcc/lcc/bin/../../binutils/bin/ld: No such file or directory
    Paul Ruiz
    @pnru_gitlab
    Great! Add -c to your lcc command line and you will end up with a hello.o object file.
    No need for the -o option, that is automatic.
    Lawrie Griffiths
    @lawrie
    root@buildroot:~# lcc -Wo-lccdir=/riscv32_lcc/lcc/bin -target=riscv32 -c hello.c
    Assembling module '/tmp/lcc1121.s'...
    root@buildroot:~# cat hello.o
    2��000#&�#,�� �$�g�Hello world!
    Paul Ruiz
    @pnru_gitlab
    That looks correct: an object file with the string constants at the end. If you also add the bof utility from binutils you can get a pretty print of the obj file contents.
    Lawrie Griffiths
    @lawrie
    I have built ld now. If I omit the -c, I get@
    root@buildroot:~# lcc -Wo-lccdir=/riscv32_lcc/lcc/bin -target=riscv32 hello.c
    Assembling module '/tmp/lcc1441.s'...
    Reading module '/tmp/lcc1442.o'...
    Usage: /riscv32_lcc/lcc/bin/../../binutils/bin/ld
             [-h]             do not write object header
             [-o objfile]     set output file name
             [-m mapfile]     produce map file
             [-rc addr]       relocate code segment
             [-rd addr]       relocate data segment
             [-rb addr]       relocate bss segment
             file             object file name
             [files...]       additional object files
    Paul Ruiz
    @pnru_gitlab
    Yes, I can help with that. Need to step away for 10 mins. If you compile ar and ranlib as well in the meantime I'll post my ld notres next.
    Lawrie Griffiths
    @lawrie
    root@buildroot:~# dof -a hello.o
    Header
        size of code         :       48 bytes
        size of data         :       16 bytes
        size of bss          :        0 bytes
        size of code relocs  :       48 bytes
        size of data relocs  :        0 bytes
        size of symbol table :       48 bytes
        size of string space :       12 bytes
    
    Code Segment
    00000000:  13 01 01 FD 23 26 81 02 13 04 01 02 23 2C 11 00   ....#&......#,..
    00000010:  17 06 00 00 13 06 06 00 EF 00 00 00 13 05 00 00   ................
    00000020:  83 20 81 01 03 24 C1 02 13 01 01 03 67 80 00 00   . ...$......g...
    
    Data Segment
    00000000:  48 65 6C 6C 6F 20 77 6F 72 6C 64 21 0A 00 00 00   Hello world!....
    
    Code Relocation Records
        0:
            offset  = 0x00000018
    Error: illegal relocation method
    Paul Ruiz
    @pnru_gitlab
    That is what I get. There seems to be a bug for printing the relocation table(s). Use option -s to at least get an overview of the symbols that are defined/referenced by the object file.
    Lawrie Griffiths
    @lawrie
    If I compile a program (life.c) that just returns 42, I can link it with ld life.o, but the a.out is not executable.
    Paul Ruiz
    @pnru_gitlab

    Ok. The linker/loader was not integrated with the lcc front end. I've posted a revised unix.c file here: https://gitlab.com/pnru/ulx3s-misc/-/blob/master/tmp/linux.c
    This has the default path set to /riscv32_lcc/lcc/bin and adds some forgotten / separators.

    It also adapts the options given to ld to something it actually understands. It now tells the linker to look for the library c.lib in the directory "/riscv32_lcc/lcc/bin/../../lib". I.e. that lib needs to be here: /riscv32_lcc/lib/c.lib

    The c.lib file (the combination of all the separate libs in the default build) is here:
    https://gitlab.com/pnru/ulx3s-misc/-/blob/master/tmp/c.lib
    Lawrie Griffiths
    @lawrie
    What architecture is that c.lib for?
    How did you produce it?
    Paul Ruiz
    @pnru_gitlab
    It is an archive with a.out object files for riskv. The object files have been compiled with the cross compiler.
    First I did the standard compile. This build all the library components in lcc/bin/libs. Then I used the ar & ranlib from binutils to combine all the object files into a single archive.
    Just a manual string of commands:
    ar -r c.lib stdlib/*.o , ar -r c.lib stdio/*.o etc. with the last one using ar -rsv c.lib string/*.o to also generate the ranlib index.
    Paul Ruiz
    @pnru_gitlab

    If I compile a program (life.c) that just returns 42, I can link it with ld life.o, but the a.out is not executable.

    It is a valid a.out executable, but ld forgets to switch on the x flag. Do chmod +x a.out to fix that, but it won't work unless your Linux accepts a.out files.

    Lawrie Griffiths
    @lawrie
    Yes I did the chmod, but I don't think Linux will accept the a.out without extra config options.
    Lawrie Griffiths
    @lawrie
    The change to linux.c didn't seem to work for me. I'll look at it again tomorrow.
    And when using ld directly:
    Paul Ruiz
    @pnru_gitlab

    There are some quirks in ld that need fixing (it now leaves a lot of debris when linking stuff from the C library and that debris then messes up subsequent runs). That is not too hard.

    Then the C library needs real code in the system call stubs. That is not hard, but I do not know how riskv Linux wants its system calls - presumably the arguments need to go into certain registers and then there has to be a software interrupt or trap of some kind, but I'm blank on specifics. Maybe @Dolu1990 knows.

    Is it very difficult to build your linux kernel with support for a.out? Or just a tweak and a compile?

    Lawrie Griffiths
    @lawrie
    root@buildroot:~# ld hello.o /riscv32_lcc/lib/c.lib 
    Reading module 'hello.o'...
    Reading module '/riscv32_lcc/lib/c.lib'...
    Error: wrong magic number in exec header
    It should be easy enough to add the two CONFIG options that I think give a.out support, but I don't know if that is sufficient.
    Paul Ruiz
    @pnru_gitlab
    Ah, of course: I was building the c.lib on x86 which is little endian. riscv32 is big endian, and we can't just copy. Luckily, you have already enough working to be able to build the c.lib natively on riskv. A project for another day, as you say.
    Maybe I spoke too soon. Your command line is wrong. The link command would be:
    ld -l /riscv32_lcc/lib/c.lib hello.o
    Lawrie Griffiths
    @lawrie
    root@buildroot:~# ld -l /riscv32_lcc/lib/c.lib hello.o
    Reading module 'hello.o'...
    Using Library:/riscv32_lcc/lib/c.lib
    [  700.670829] ld[124]: unhandled signal 11 code 0x1 at 0x00e46c30 in libc-2.29.so[3569a000+149000]
    [  700.676835] CPU: 2 PID: 124 Comm: ld Tainted: G        W         5.0.9 #1
    [  700.682157] sepc: 35711650 ra : 00012a34 sp : 9fe46bb0
    [  700.686248]  gp : 0001bd14 tp : 35577de0 t0 : 0001e010
    [  700.690075]  t1 : 00010c9c t2 : 00000000 s0 : 9fe46bf0
    [  700.693304]  s1 : 9fe46c08 a0 : 00e46c31 a1 : 000249a0
    [  700.698437]  a2 : 9fe46c08 a3 : 00000000 a4 : 00000000
    [  700.703855]  a5 : 000249a0 a6 : fefefeff a7 : 0000003f
    [  700.709083]  s2 : 000da247 s3 : 00000000 s4 : 000e1454
    [  700.714653]  s5 : 35577e08 s6 : 00000008 s7 : 00000002
    [  700.720056]  s8 : 00000014 s9 : 35577e08 s10: 000c08e8
    [  700.725350]  s11: 000e49b5 t3 : 3571164c t4 : 0005f1c4
    [  700.730665]  t5 : 00000000 t6 : 00000000
    [  700.735003] sstatus: 00000020 sbadaddr: 00e46c30 scause: 0000000d
    Segmentation fault
    Paul Ruiz
    @pnru_gitlab
    Hmmm.. bummer. Maybe still endianness, but I am guessing at this point. Still, a nice amount of progress today.
    Lawrie Griffiths
    @lawrie
    Yes, thanks for the help.
    Paul Ruiz
    @pnru_gitlab
    By the way, for debugging linux.c, you can call lcc with the -v flag, and it will print out the exact command lines that it is trying to execute.
    Lawrie Griffiths
    @lawrie
    root@buildroot:~# lcc -v -Wo-lccdir=/riscv32_lcc/lcc/bin -target=riscv32 hello.c
    lcc $Id$
    /riscv32_lcc/lcc/bin/ucpp -DLANGUAGE_C -D_LANGUAGE_C -DUNIX -D_UNIX -Dunix -zI -D__LCC__ -I/riscv32_lcc/lcc/bin/include hello.c -o /tmp/lcc1340.i
    /riscv32_lcc/lcc/bin/rcc -target=riscv32 -v -target=riscv32 /tmp/lcc1340.i /tmp/lcc1341.s
    /riscv32_lcc/lcc/bin/rcc $Name$($Id$)
    /riscv32_lcc/lcc/bin/../../binutils/bin/as -o /tmp/lcc1342.o /tmp/lcc1341.s
    Assembling module '/tmp/lcc1341.s'...
    /riscv32_lcc/lcc/bin/../../binutils/bin/ld -o a.out -l /riscv32_lcc/lcc/bin/../../lib/c.lib -L/riscv32_lcc/lcc/bin
    Usage: /riscv32_lcc/lcc/bin/../../binutils/bin/ld
             [-h]             do not write object header
             [-o objfile]     set output file name
             [-m mapfile]     produce map file
             [-rc addr]       relocate code segment
             [-rd addr]       relocate data segment
             [-rb addr]       relocate bss segment
             file             object file name
             [files...]       additional object files
    rm /tmp/lcc1342.o /tmp/lcc1340.i /tmp/lcc1341.s
    Paul Ruiz
    @pnru_gitlab
    With the arguments to ld you do not need the "-L" option. This particular version of ld does not support that option (capital L).
    You do not need this -Wo-lccdir=/riscv32_lcc/lcc/bin -target=riscv32 either anymore. That is now the default. I forgot to remove this line:
    https://gitlab.com/pnru/ulx3s-misc/-/blob/master/tmp/linux.c#L64
    Lawrie Griffiths
    @lawrie
    It didn't seem to pass the /tmp/lcc1341.s file to ld.
    root@buildroot:~# lcc -v hello.c
    lcc $Id$
    /riscv32_lcc/lcc/bin/ucpp -DLANGUAGE_C -D_LANGUAGE_C -DUNIX -D_UNIX -Dunix -zI -D__LCC__ -I/riscv32_lcc/lcc/bin/include hello.c -o /tmp/lcc1440.i
    /riscv32_lcc/lcc/bin/rcc -target=riscv32 -v /tmp/lcc1440.i /tmp/lcc1441.s
    /riscv32_lcc/lcc/bin/rcc $Name$($Id$)
    /riscv32_lcc/lcc/bin/../../binutils/bin/as -o /tmp/lcc1442.o /tmp/lcc1441.s
    Assembling module '/tmp/lcc1441.s'...
    /riscv32_lcc/lcc/bin/../../binutils/bin/ld -o a.out -l /riscv32_lcc/lcc/bin/../../lib/c.lib /tmp/lcc1442.o
    Reading module '/tmp/lcc1442.o'...
    Using Library:/riscv32_lcc/lcc/bin/../../lib/c.lib
    [ 1734.690634] ld[148]: unhandled signal 11 code 0x1 at 0x00f82be0 in libc-2.29.so[3569a000+149000]
    [ 1734.696771] CPU: 0 PID: 148 Comm: ld Tainted: G        W         5.0.9 #1
    [ 1734.702501] sepc: 35711650 ra : 00012a34 sp : 9ff82b60
    [ 1734.706588]  gp : 0001bd14 tp : 35577de0 t0 : 0001e010
    [ 1734.710499]  t1 : 00010c9c t2 : 00000000 s0 : 9ff82ba0
    [ 1734.714470]  s1 : 9ff82bb8 a0 : 00f82be1 a1 : 000249b0
    [ 1734.718588]  a2 : 9ff82bb8 a3 : 00000000 a4 : 00000000
    [ 1734.723807]  a5 : 000249b0 a6 : fefefeff a7 : 0000003f
    [ 1734.728990]  s2 : 00017364 s3 : 00000000 s4 : 000e140c
    [ 1734.734944]  s5 : 35577e08 s6 : 00000008 s7 : 00000002
    [ 1734.739800]  s8 : 00000014 s9 : 35577e08 s10: 000c08e8
    [ 1734.746030]  s11: 000e49b5 t3 : 3571164c t4 : 0005f1c4
    [ 1734.750554]  t5 : 00000000 t6 : 00000000
    [ 1734.754953] sstatus: 00000020 sbadaddr: 00f82be0 scause: 0000000d
    lcc: fatal error in /riscv32_lcc/lcc/bin/../../binutils/bin/ld
    rm /tmp/lcc1442.o /tmp/lcc1440.i /tmp/lcc1441.s
    Have not built with the -L line removed yet.