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

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #30 on: May 10, 2021, 09:13:59 pm »
Well, that fails with a weak prelinker fail.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #31 on: May 10, 2021, 09:44:01 pm »
This might work, though it fails using the old gcc_elf like this,
Code: [Select]
H:\tmp>wl  @hello.lnk
** EXPERIMENTAL (HLL) ** Open Watcom Linker Version 2.0beta1 Limited Availability
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
Error! E2028: printf is an undefined reference
Error! E2028: _main is an undefined reference
creating map file
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
Perhaps just the calling convention, with an OMF produced by GCC 9.2.0
Code: [Select]
H:\tmp>wl  @hello.lnk
** EXPERIMENTAL (HLL) ** Open Watcom Linker Version 2.0beta1 Limited Availabilit
y
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
And a working hello.exe

hello.lnk
Code: [Select]
FORMAT OS2 LX
DEBUG ALL
file Hello.o
file W:\usr\lib\crt0.obj
OPTION MAP=Hello
OPTION DESCRIPTION 'Elf test'
OPTION ELIMINATE
OPTION MANYAUTODATA
OPTION OSNAME='OS/2 and ArcaOS'
OPTION SHOWDEAD
LIBRARY W:\usr\lib\gcc\i686-pc-os2-emx\9\libgcc_so_d.lib
LIBRARY W:\usr\lib\libc_alias.lib
LIBRARY W:\usr\lib\libc_dll.lib
LIBRARY W:\usr\lib\libend.lib

Obviously adjust the libraries paths. It's a start anyways. Invoked as wl.exe @hello.lnk.  Does work given an OMF hello.o

Paul Smedley

  • Hero Member
  • *****
  • Posts: 2092
  • Karma: +159/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #32 on: May 11, 2021, 11:15:20 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

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #33 on: May 12, 2021, 04:20:19 am »
I still think that emxomfld could be stripped down by not converting and bypassing the weak linker to call wl.exe. This may also result in needing the minimum changes to GCC.

Paul Smedley

  • Hero Member
  • *****
  • Posts: 2092
  • Karma: +159/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #34 on: May 12, 2021, 05:01:46 am »
Hey Dave,

I still think that emxomfld could be stripped down by not converting and bypassing the weak linker to call wl.exe. This may also result in needing the minimum changes to GCC.

I'm still thinking about how best to handle it. We may still WANT to convert to OMF in some cases in order to use the 'classic' debuggers.

Of course, switching to ELF may make gdb easier to compile/work.

Just thinking out load, I was considering introducing -Zelf to tell GCC to invoke as_elf.exe rather than as.exe - that also opens up the use of -Zelf -Zomf to use ELF initially, but convert to OMF at link time (if we have a suitable ELF -> OMF converter that makes the exercise worthwhile).

I'll probably hack something together short term and make sure that 'stuff' works, then think about how best to support a.out, elf & OMF object formats in a more flexible manner...

Cheers,

Paul.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #35 on: May 12, 2021, 06:54:27 am »
It's the ELF to OMF converter that is hard. It's a shame that the source for elfomf is lost, I have a binary but being GPL...
There is also objconv, https://www.agner.org/optimize/#objconv which I noticed didn't like our OMF when I tried to convert to ELF.

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #36 on: May 12, 2021, 07:05:04 am »
if we have a suitable ELF -> OMF converter that makes the exercise worthwhile

"ELF -> OMF converter"   is not  a good way  from point of view of alignment.

AFAIK   OMF support  2,4,16,4K  only  and thus  data   cannot be aligned  to 64 and 128
« Last Edit: May 12, 2021, 02:20:53 pm by OS4User »

Paul Smedley

  • Hero Member
  • *****
  • Posts: 2092
  • Karma: +159/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #37 on: May 12, 2021, 08:02:15 am »
@os4user I'm not disagreeing with you, but if we don't convert to omf, how do we debug on OS/2?

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #38 on: May 12, 2021, 08:20:45 am »
"ELF -> OMF converter"   is not  a good way  from point of view of alignment.

AFAIK   OMF support  2,8,16,4K  only  and thus  data   cannot be aligned  to 64 and 128

From the NASM docs, https://www.nasm.us/xdoc/2.15.05/html/nasmdoc8.html#section-8.4.1
Quote
ALIGN is used, as shown above, to specify how many low bits of the segment start address must be forced to zero. The alignment value given may be any power of two from 1 to 4096; in reality, the only values supported are 1, 2, 4, 16, 256 and 4096, so if 8 is specified it will be rounded up to 16, and 32, 64 and 128 will all be rounded up to 256, and so on. Note that alignment to 4096-byte boundaries is a PharLap extension to the format and may not be supported by all linkers.

Now what wlink supports is another question.



OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #39 on: May 12, 2021, 02:45:24 pm »
From the NASM docs, https://www.nasm.us/xdoc/2.15.05/html/nasmdoc8.html#section-8.4.1

from OMF spec:
...
A  Alignment
A 3-bit field that specifies the alignment required when this program segment is placed within a
logical segment. Its values are:
   0 Absolute segment.
   1 Relocatable, byte aligned.
   2 Relocatable, word (2-byte, 16-bit) aligned.
   3 Relocatable, paragraph (16-byte) aligned.
   4 Relocatable, aligned on a page boundary. (The original Intel 8086 specification
      defines a page to be 256 bytes. The IBM implementation of OMF uses a 4096-byte or 4K  page size).
   5 Relocatable, aligned on a double word (4-byte) boundary.
   6 Not supported.
   7 Not defined.

So for OMF we have 1,2,4,16,4K  only, with no relation what is supported by NASM.


Paul Smedley

  • Hero Member
  • *****
  • Posts: 2092
  • Karma: +159/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #40 on: May 13, 2021, 10:39:58 am »
Hi All,

I still think that emxomfld could be stripped down by not converting and bypassing the weak linker to call wl.exe. This may also result in needing the minimum changes to GCC.

I'm still thinking about how best to handle it. We may still WANT to convert to OMF in some cases in order to use the 'classic' debuggers.

Of course, switching to ELF may make gdb easier to compile/work.

Just thinking out load, I was considering introducing -Zelf to tell GCC to invoke as_elf.exe rather than as.exe - that also opens up the use of -Zelf -Zomf to use ELF initially, but convert to OMF at link time (if we have a suitable ELF -> OMF converter that makes the exercise worthwhile).

I'll probably hack something together short term and make sure that 'stuff' works, then think about how best to support a.out, elf & OMF object formats in a more flexible manner...

Thinking some more.... I think I'll fork emxomfld.c and create an emxelfld.c which will do the following:
- use wlink by default
- use noautocnv by default to ensure we don't try and convert elf to OMF

This should make it easy to add -Zelf to gcc which would use emxelfld.exe as the linker

The bit I haven't worked out yet is how to tell gcc to use as_elf.exe not as.exe

It may be that the gcc elf needs to be a completely separate install to gcc aout/omf

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #41 on: May 13, 2021, 11:21:27 am »
@os4user I'm not disagreeing with you, but if we don't convert to omf, how do we debug on OS/2?

I am not familiar with this matter and have no idea why object files are needed for debugging.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #42 on: May 13, 2021, 05:38:32 pm »
@os4user I'm not disagreeing with you, but if we don't convert to omf, how do we debug on OS/2?

I am not familiar with this matter and have no idea why object files are needed for debugging.

The real question is the amount of support for our stabs (dwarf?) debugging data in elf object files and whether the linker can put that data in the executable.
Currently, my understanding is that aout supports stabs and emxomf transfers the stabs to the omf intermediate objs and then the linker transfers them to the executable or a dbg file. Not sure if our debuggers support dbg files, exceptq does.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #43 on: May 13, 2021, 05:53:45 pm »
Hi Paul, really first it needs to be checked out whether OMF is needed for debugging or whether ELF can handle it along with wl.exe putting it into the executable. Currently debugging works fine with our aout-->omf-->linker-->exe/dll.
I'd suggest testing and possibly it might work or wl.exe can be altered for it to work.
There's also the weak linker to consider. Reading up on it, it is probably seldom used and can be ignored for now. https://en.wikipedia.org/wiki/Weak_symbol

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: Alternatives to compiling Rust in Firefox port OS/2
« Reply #44 on: May 13, 2021, 06:15:36 pm »
The real question is the amount of support for our stabs (dwarf?) debugging data in elf object files and whether the linker can put that data in the executable.
Currently, my understanding is that aout supports stabs and emxomf transfers the stabs to the omf intermediate objs and then the linker transfers them to the executable or a dbg file. Not sure if our debuggers support dbg files, exceptq does.

Good point...

AFAIK wl supports  dwarf.  Is only question if  as_elf   can generate it.