search

joncampbell123 / doslib

Hackipedia DOSLIB, a general collection of useful libraries for writing MS-DOS software
GNU Lesser General Public License v2.1
210 stars 18 forks source link

OMFSEGDG fails to recognize FIXUP to PUBDEF symbol that is not part of DGROUP #17

Open joncampbell123 opened 7 years ago

joncampbell123 commented 7 years ago

Test case found:

Compiling the hw/isapnp project in tiny model initially failed because the devnode_raw array was declared far.

Watcom C generates OMF records putting it into it's own segment. That segment is NOT part of DGROUP. But that is not obvious from the FIXUP record.

LNAMES (from 11): [11]: "test13_DATA" [12]: "FAR_DATA"
OMF record type=0x98 (SEGDEF: Segment Definition Record) length=6 offset=755 blocksize=0
SEGDEF (5):
    Alignment=PARA(3) combination=PRIVATE(0) big=0 frame=16 offset=0 use0
    Length=4096 name="test13_DATA"(11) class="FAR_DATA"(12) overlay=""(1)

..

FIXUPP[95]:
    seg-relative location=16BIT-SEGBASE(2) frame_method=by-TARGET(5)
    target_method="EXTDEF"(2) target_index="_devnode_raw"(11) data_rec_ofs=0x5F(95)
    target_displacement=0 ledata_rec_ofs=0x1539(5433)+3 absrecofs=0x18F(399)

..

OMF record type=0xb6 (LPUBDEF: Local Public Names Definition Record) length=18 offset=14413 blocksize=0
PUBDEF (2):
    [2] "_devnode_raw" group=""(0) segment="test13_DATA"(5) offset=0x0(0) typeindex=0 LOCAL

The tool currently assumes all EXTDEFs are in the same DGROUP. Here is a case where an EXTDEF refers to a PUBDEF (publicly defined symbol). OMFSEGDG already gathers symbols in the first pass, so it has the ability in the second pass to determine where the symbol is and whether or not it is part of DGROUP.

joncampbell123 commented 6 years ago

A related bug has cropped up where more than one DATA segment results in an OMF file that only carries the first data segment, resulting in an invalid file.