Opened 2 years ago

Last modified 2 years ago

#376 new defect

emxomfld: Invalid WKEXT record

Reported by: dmik Owned by:
Priority: normal Milestone: new
Component: emx Version: 0.6.6
Severity: normal Keywords:
Cc:

Description

Happens when linking a really huge XUL.DLL (400MB or os). Comments from here https://github.com/bitwiseworks/mozilla-os2/issues/188#issuecomment-293347063:

Turns out that the link failure is due to this def in weakld.c (part of EMXOMFLD.EXE)

#define OMF_GETINDEX()  (*u.puch & 0x80 ? ((*u.pch++ & 0x7f) << 8) + *u.pch++ : *u.pch++)

being:

  • Wrongly compiled by GCC 3.3.5 with regard to operator precedence order or such (looks like the compiler bug so far) which leads to a wrong value used as the result of the expression.
  • Containing a signed/unsigned bug so that the result is always a negative int if the first byte has a 0x80 bit and the second byte has it as well.

Due to these problems, a weak symbols's index was computed as a negative value out of index table bounds, hence the Invalid WKEXT record error.

With this version of the macro:

#define OMF_GETINDEX()  (*u.puch & 0x80 ? ((*u.pch++ & 0x7f) << 8) + *u.puch++ : *u.pch++)

and with EMXOMFLD.EXE built by GCC 4.9.2 I get past this Invalid WKEXT record error.

Change History (1)

comment:1 Changed 2 years ago by dmik

Note that I didn't bother myself finding out why GCC 3.x builds this code wrongly so far (as I really believe LIBC should be rebuilt with a newer GCC — here GCC 4.x builds it pretty well with some obvious fixes here and there).

Note: See TracTickets for help on using tickets.