fixupp: Modify to add group declaration to symbols?
(Not really EDR-DOS related, just want to use it as a base to build upon.)
This is concerning https://bugzilla.nasm.us/show_bug.cgi?id=3392916
I'm considering to adapt the fixupp tool as written by @boeckmann to handle this problem, so that the old MASM versions included in MS-DOS v2 / MSDebug (no more) / MS-DOS v4 can interoperate with NASM without a different hack to work around this problem.
It should be easy enough, right?
Sounds reasonable. What exactly is your intention? Adding the group info to PUBDEFs with given segments that are part of a group?
As another data point to your finding mentioned in the NASM bugzilla: Borland TASM also adds the group to publics with the segment being member of a group.
ideal
group dgroup data
segment data
public exported
exported:
mov ax,1
ends
end
results in:
...
98 SEGDEF16 7 bytes, checksum FA (valid)
PARA (A3) PRIVATE (C0) USE16 size 0003
name 'DATA'
0000: 60 03 00 02 01 01 : `.....
...
9a GRPDEF 4 bytes, checksum 5F (valid)
name 'DGROUP'
segment 'DATA'
0000: 03 ff 01 : ...
90 PUBDEF16 15 bytes, checksum EC (valid)
segment 'DATA' group 'DGROUP'
[0001] public name 'EXPORTED' offset 0000
0000: 01 01 08 45 58 50 4f 52-54 45 44 00 00 00 : ...EXPORTED...
Sounds reasonable. What exactly is your intention? Adding the group info to PUBDEFs with given segments that are part of a group?
Yes, exactingly.
Sure we can implement this. Should not be that much effort.
So seems to affect all MASM versions up to 5.1 (inclusive)? This would at least be consistent with the other group handling of these versions. I guess they changed it with MASM 6 like they did with the segment frame parts of the fixupps? Would explain why JWasm behaves like you described.
For reference, here's the prior thread where we modified fixupp: https://github.com/SvarDOS/edrdos/issues/61
I will upload a patch later. Still have to test it but it seems to work.
https://hg.pushbx.org/ecm/fixupp/rev/7888d52b621a I uploaded it into a separate repo, here.
Looks good :) I also considered moving it to its own repo, as it is not used by this repo anymore. Perhaps this can be combined with the omfdump repo, renaming it to omftools, because I also want to make some other small tools like bin2omf and omf2bin (single-file "linker", as training excercise for a multi-file linker) etc. These could be placed inside this new repo.
https://hg.pushbx.org/ecm/fixupp/rev/7888d52b621a I uploaded it into a separate repo, here.
I changed the history of the repo so it only has ltools/fixupp.c in the entire history, to avoid carrying along the entire edrdos history. This link is now obsolete and superseded by https://hg.pushbx.org/ecm/fixupp/rev/6a93ef61628b
I also added a display of the segment and group being used in the "Replacing ..." line, at https://hg.pushbx.org/ecm/fixupp/rev/3df98a3ba63c
If you care I collected the scriptlets I used to extract the file history from the edrdos repo in https://hg.pushbx.org/ecm/fixupp/rev/5a3b35d61c9b
Looks good :) I also considered moving it to its own repo, as it is not used by this repo anymore. Perhaps this can be combined with the omfdump repo, renaming it to omftools, because I also want to make some other small tools like bin2omf and omf2bin (single-file "linker", as training excercise for a multi-file linker) etc. These could be placed inside this new repo.
Feel free to pick it into your omfdump or omftools repo.
I took the liberty to quote you in the NASM bz: https://bugzilla.nasm.us/show_bug.cgi?id=3392916#c7
@ecm-pushbx I mirrored your mercurial repo to my mercurial fixupp repo at sourcehut. I was too lazy to setup my own mercural infrastructure, and sourcehut seems to be one of the few hosters still supporting mercurial.
I will push my changes (if there are any) to fixupp to this hg repo. I also made a omftools hg repo (currently empty). I will try to import the commits made to my omfdump Git repo to omftools with the commit log stayed intact. Not sure yet if I should include fixupp in this repo. Probably better to leave out for now...
I noticed that the FIXUPP of this repo did not build with GCC14 under Linux because of a warning treated as error, so I imported your recent changes. This version does build. Alternative would have been to remove fixupp.c altogether from this repo, but as the RASM86.EXE is also still contained I prefer leaving it in for now.
Can you recreate and quote the error/warning?
Wouldn't my new Linux installation not have crashed while going into standby I could have copied it from the terminal buffer. But I will try to reproduce with the older commit...
Ok, false warning. The "thing" that did not build was a local modification of mine that did not went into the repo (I started working on fixupp implementing your requested changes, but you already had it nearly finished, so I stopped working on it...).
I just today installed Linux on my PC and first thing I did was setup syncthing to sync my files from the MacBook (Git repos inclusive). Then tried to build and GCC threw errors... But like said before, it was some local modification.
I modified fixupp again. This time, to solve a NASM deficiency that it doesn't allow a symbol that starts with dollar signs, which I want for certain WarpLink sources.
I modified fixupp again. This time, to solve a NASM deficiency that it doesn't allow a symbol that starts with dollar signs, which I want for certain WarpLink sources.
Imported it to my Mercurial repo at https://sr.ht/~boeckmann/omftools/
More specifically https://hg.sr.ht/~boeckmann/fixupp
imported to this git repo via
hg export --git -r 23 > ~/Temp/fixupp-23.patch
then from the inside the Git repo:
cat ~/Temp/fixupp-23.patch | hg-patch-to-git-patch | git am
Made use of it to port the default overlay manager to NASM: https://hg.pushbx.org/ecm/warplink/file/719d9c7c2e66/ovlmgr.nas
The D. to dollar sign makes convlist.pl choke, so I had to massage the .lst file as well:
cp ~/proj/warplink/repo/ovlmgr.lst -a . &&
perl -i -pe 's/\b((D\.)+)/"\$" x (length("$1")\/2)/e' ovlmgr.lst &&
convlist.pl test.map ovlmgr.lst > testmain.tls
Then using the extended map file and the .tls file of a test application I was able to run ident86:
~/proj/ident86/ident86.py -s original/test.exe test.exe testmain.tls test.map | tee report.txt