Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.os2.programmer.porting > #92

Re: GCC + WLINK

Show all headers | View raw

Ruediger Ihle wrote:
> On Sat, 25 Jun 2011 16:37:24 UTC, Dave Yeo<dave.r.yeo@gmail.com>  wrote:
>
>> I think only wl.exe on Netlabs works with GCC. As far as I
>> know the main change is the debugging support.
>> You can always test by setting EMXOMFLD_LINKER to wlink.exe.
>
> I just did that. It looks like in principle a different version of
> WLINK can be used. Except GCC is instructed to build a debug version.
> In this case it emits a directive to select the format of the
> debugging info. A "plain vanilla" WLINK doesn't understand the
> "HLL" format introduced in the Netlabs version and will bail out
> with an error message.

OK, that's good to know.

>
> Question: Is there an environment variable to tell GCC not to issue
> the "HLL" directive or - better - to specify an alternate debug info
> format ? Given that WLINK supports DWARF, it might be possible that
> a refreshed port of GDB would be able to make use of that.

As I understand it, GCC just outputs stabs 
(http://sourceware.org/gdb/current/onlinedocs/stabs/index.html) attached 
to a.out and emxomf converts it to HLL. See 
http://svn.netlabs.org/libc/browser/branches/libc-0.6/src/emx/src/emxomf/stabshll.c
I think that GDB can handle stabs directly so a refreshed GDB port could 
handle executable built without -Zomf. At least it worked with GCC 2.8.1 
and the old GDB.
The EMX GDB port is ancient along with some other parts of the toolchain 
so a port would really have to be done from scratch as far as I can see.
Another possibility is for GCC to output ELF with DWARF attached. Some 
work has been done in this direction with libc07 emxomfar and emxomfld 
having some support for mixed object formats and wlink being able to 
link ELF and possibly link mixed ELF and OMF. Need to test that one day.

>> We've been using wl.exe to build Firefox etc. Seems to work and can
>> handle larger DLLs then ilink.
>
> Looking at the README in the JAVA project it seems that none of the
> linkers is really working correctly and the programmer has to find
> out by trial an error which one might be able to produce working
> executables.

Yea, I've hit limits with both linkers. Last night I also was trying to 
build a debug version of Firefox and couldn't build gklayout.lib as 
emxomfar kept running out of memory. Seems 1.5 GB process space was too 
small and as I only have 768 MBs the swapping was very excessive :)
Windows has also been having similar problems with their linker with 
workarounds consisting of using the /3GB flag which can lead to 
instabilities due to bad device drivers or using the 64 bit version 
which seems to be able to allocate close to a full 4 GBs in a 32 bit 
process.
Depressingly we're hitting hard limits with our designed in 1990 
operating system.
Dave

Back to comp.os.os2.programmer.porting | Previous | Next — Previous in thread | Find similar

Thread

GCC + WLINK "Ruediger Ihle" <NOSPAM$R.Ihle@S-t.De> - 2011-06-25 14:05 +0000
  Re: GCC + WLINK Dave Yeo <dave.r.yeo@gmail.com> - 2011-06-25 09:37 -0700
    Re: GCC + WLINK "Ruediger Ihle" <NOSPAM$R.Ihle@S-t.De> - 2011-06-26 11:43 +0000
      Re: GCC + WLINK Dave Yeo <dave.r.yeo@gmail.com> - 2011-06-26 12:54 -0700

csiph-web