Author Topic: Alternatives to compiling Rust in Firefox port OS/2  (Read 7349 times)

Paul Smedley

  • Hero Member
  • *****
  • Thank You
  • -Given: 63
  • -Receive: 129
  • Posts: 894
  • Karma: +81/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #45 on: May 13, 2021, 11:53:18 pm »
Status:

Minor tweaks to GCC made to always invoke emxelfld as the linker.

- emxelfld.c forked from emxomfld.c (copy at https://smedley.id.au/tmp/emxelfld.c)
- emxomfld checkomf function modified to also check for elf header and not attempt to convert it to OMF - we want the autoconvert code as we may be trying to link against an a.out library or object file (eg crt0.o)
- emxomfld - don't call weak_prelink() (as weakld doesn't understand elf)


Currently failing to link an executable with:
gcc -Zexe -Zomf -o hello.exe helloworld.c
Error! E2026: redefinition of reserved symbol _edata
Error! E2026: redefinition of reserved symbol __edata
Error! E2026: redefinition of reserved symbol _end
Error! E2026: redefinition of reserved symbol __end

This is similar to the error Dave was getting earlier with wl.exe - more investigation required....

TODO: (other than fix linked an exe)
- Update as_elf to something more modern than binutils 2.9.1
- work out how to workaround the lack of elf support in emximp - in order to create import libraries for DLL's - worst case is to use OMF libs
« Last Edit: May 14, 2021, 12:22:41 am by Paul Smedley »

Paul Smedley

  • Hero Member
  • *****
  • Thank You
  • -Given: 63
  • -Receive: 129
  • Posts: 894
  • Karma: +81/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #46 on: May 14, 2021, 12:25:53 am »
Removing libend.lib from the linking step allows an executable to be created, but running it gives:
Killed by SIGILL
pid=0xf202 ppid=0x776e tid=0x0001 slot=0x009d pri=0x0200 mc=0x0001 ps=0x0010
U:\DEV\T\HELLOWORLD.EXE
HELLOWOR 0:00000024
cs:eip=005b:00010024      ss:esp=0053:00027f6c      ebp=00027f88
 ds=0053      es=0053      fs=150b      gs=0000     efl=00012206
eax=00000000 ebx=00027f90 ecx=1c8dc060 edx=1c8dc068 edi=00000000 esi=00000000
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 13
  • -Receive: 229
  • Posts: 3216
  • Karma: +62/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #47 on: May 14, 2021, 03:06:11 am »
If I'm understanding https://sourceware.org/gdb/onlinedocs/stabs.html correctly, elf can put the stabs in its own section much like aout does. So it should be possible and with luck might work out of the box. Hopefully it'll fix those warnings about too big stabs that are generated while compiling.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 13
  • -Receive: 229
  • Posts: 3216
  • Karma: +62/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #48 on: May 14, 2021, 03:26:43 am »
- work out how to workaround the lack of elf support in emximp - in order to create import libraries for DLL's - worst case is to use OMF libs
There's the IMPLIB option for wlink to create an implib during linking. Hmm, it actually calls wlib to create the import library.
Wlib also has the option ie to create elf import records and an option to list all symbols found in a library file, including static.
There's other tools available, some from binutils some from OW which could be tweaked to output exports from object files.
Wlink has a variety of way to create a DLL, with def files hardly used though they work. With the screensaver's cairo clock, I imported the symbols directly from cairo2.dll and the makefile has,
Code: [Select]
$(dllname).dll: $(object_files)
    @wlink system 386 lx dll INITINSTANCE TERMINSTANCE name $(dllname) &
    f CaClock f MSGX op MAP=$(dllname) op DESC 'Cairo Clock - ScreenSaver module
' &
    op ELIMINATE op MANYAUTODATA op OSNAME='OS/2 and eComStation' op SHOWDEAD &
    LIBPATH %os2tk%\lib LIBRARY libuls.lib LIBRARY libconv.lib @Imports.lnk @des
cription

!ifdef has_resource_file
    rc $(rcname) $(dllname).dll
!endif
!ifdef create_packed_dll
    lxlite $(dllname).dll
!endif

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 13
  • -Receive: 229
  • Posts: 3216
  • Karma: +62/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #49 on: May 14, 2021, 05:37:48 am »
Thanks everyone... what works here is:

Code: [Select]
gcc -S helloworld.c
as_elf helloworld.s -o helloworld.o
wl @hello.lnk
** EXPERIMENTAL (HLL) ** Open Watcom Linker Version 2.0beta1 Limited Availability by SHL on Jul  2 2020
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
creating map file
creating an OS/2 and ArcaOS executable

For interest - https://smedley.id.au/tmp/helloworld.zip

I have a day off on Friday, I'll try and think about how to modify GCC to use this stuff....

Cheers,

Paul

'tis weird, this worked the other day, today I'm getting the
Code: [Select]
Error! E2026: redefinition of reserved symbol _edata
Error! E2026: redefinition of reserved symbol __edata
Error! E2026: redefinition of reserved symbol _end
Error! E2026: redefinition of reserved symbol __end


Paul Smedley

  • Hero Member
  • *****
  • Thank You
  • -Given: 63
  • -Receive: 129
  • Posts: 894
  • Karma: +81/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #50 on: May 14, 2021, 06:13:45 am »
'tis weird, this worked the other day, today I'm getting the
Code: [Select]
Error! E2026: redefinition of reserved symbol _edata
Error! E2026: redefinition of reserved symbol __edata
Error! E2026: redefinition of reserved symbol _end
Error! E2026: redefinition of reserved symbol __end

Removing libend 'fixes' the linking - but I get a SIGILL trying to run the resulting executable...

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 13
  • -Receive: 229
  • Posts: 3216
  • Karma: +62/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #51 on: May 14, 2021, 06:43:16 am »
Perhaps rebuild libend with those symbols commented out?
I tried but I seem to be missing the ml assembler and building all fails due to missing demangle.h
Looking, it seems they're reserved symbols when the option DOSSEG is specified. Where it is getting specified, I'm not sure unless it is automatic when making an executable. It is possible to override the segment ordering, only recommended for embedded applications without an OS. The segments probably should be ordered in a specific order. Search for DOSSEG in the Open Watcom Linker guide.
Looking at the emxomfld source, I can't quite figure out the whole list of options being passed and why linking OMF doesn't cause the same error.

Paul Smedley

  • Hero Member
  • *****
  • Thank You
  • -Given: 63
  • -Receive: 129
  • Posts: 894
  • Karma: +81/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #52 on: May 14, 2021, 07:06:54 am »
Hey Dave,

Perhaps rebuild libend with those symbols commented out?
I tried but I seem to be missing the ml assembler and building all fails due to missing demangle.h
Looking, it seems they're reserved symbols when the option DOSSEG is specified. Where it is getting specified, I'm not sure unless it is automatic when making an executable. It is possible to override the segment ordering, only recommended for embedded applications without an OS. The segments probably should be ordered in a specific order. Search for DOSSEG in the Open Watcom Linker guide.
Looking at the emxomfld source, I can't quite figure out the whole list of options being passed and why linking OMF doesn't cause the same error.

Yeah I tried rebuilding libend with those symbols commented out - it now links but I get the same SIGILL as if I just remove libend.

I think I was confused when I thought it was working the other day - my hello.lnk had helloworld.obj in it - which was an OMF version of the object file :(

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 13
  • -Receive: 229
  • Posts: 3216
  • Karma: +62/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #53 on: May 14, 2021, 08:04:37 am »
Yeah I tried rebuilding libend with those symbols commented out - it now links but I get the same SIGILL as if I just remove libend.

Might be a problem with the section ordering

Quote
I think I was confused when I thought it was working the other day - my hello.lnk had helloworld.obj in it - which was an OMF version of the object file :(

I must have made the same mistake :) Today I fixed your hello.lnk as I had lost my original test after a reboot (ram disk) and then got the error.
Need a compiler expert who understands all these segments and stuff.

Paul Smedley

  • Hero Member
  • *****
  • Thank You
  • -Given: 63
  • -Receive: 129
  • Posts: 894
  • Karma: +81/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #54 on: May 15, 2021, 02:08:49 am »
Hey Dave,

Need a compiler expert who understands all these segments and stuff.

That rules me out then :P

Cheers,

Paul

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 13
  • -Receive: 229
  • Posts: 3216
  • Karma: +62/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #55 on: May 15, 2021, 04:10:31 am »
Yet, you probably know more then most of us, if only from hacking on the GCC source. There are people who seem to instinctively understand this stuff though, AZ who did the GCC 2.9x ports was one. IBM chased him down and payed him to do the first kLIBC GCC port, 3.22 or so for Mozilla. There was someone else who ported GCC back in the day for fun, a different port then EMX. So much software lost.

Paul Smedley

  • Hero Member
  • *****
  • Thank You
  • -Given: 63
  • -Receive: 129
  • Posts: 894
  • Karma: +81/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #56 on: May 20, 2021, 04:47:09 am »
Hi All,

Yet, you probably know more then most of us, if only from hacking on the GCC source. There are people who seem to instinctively understand this stuff though, AZ who did the GCC 2.9x ports was one. IBM chased him down and payed him to do the first kLIBC GCC port, 3.22 or so for Mozilla. There was someone else who ported GCC back in the day for fun, a different port then EMX. So much software lost.

Just an update on this - the issue with OS/2 executables and elf format object files appears to be a wl (Watcom Linker) bug. I built as.exe with coff object format and a simple hello world executable runs ok.

I'll use this to continue with some tweaks to gcc and emxelfld.exe as time permits, to see what's possible - ie can we still build a DLL with the tools and whatever other changes may be required.

Cheers,

Paul.

Paul Smedley

  • Hero Member
  • *****
  • Thank You
  • -Given: 63
  • -Receive: 129
  • Posts: 894
  • Karma: +81/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #57 on: May 20, 2021, 12:13:27 pm »
FWIW the example helloworld.o in coff format, as as-coff.exe is at https://smedley.id.au/tmp/helloworld-coff.zip

Paul Smedley

  • Hero Member
  • *****
  • Thank You
  • -Given: 63
  • -Receive: 129
  • Posts: 894
  • Karma: +81/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #58 on: May 22, 2021, 08:21:11 am »
Quick update, with https://smedley.id.au/tmp/gcc-11.1.0-os2-coff-20210522.zip - I can compile and link *C* executables with assembly produced in the COFF format. (For ELF, we have a bug with wl.exe preventing a valid executable being created).

Note c++ executables can't currently be linked. This is because weakld.c (part of emxomfld) only understand OMF, so I have currently commented out weak_prelink() in emxelfld, so we don't have weak symbols support.

For weakld,  https://github.com/bitwiseworks/libc/blob/master/src/emx/src/emxomf/weakld.c in WLDAddObject() will need to be enhanced so it understands coff (and eventually ELF).