fixupp: Modify to add group declaration to symbols?

[ecm-pushbx]

(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?

[boeckmann]

Sounds reasonable. What exactly is your intention? Adding the group info to PUBDEFs with given segments that are part of a group?

[boeckmann]

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...

[ecm-pushbx]

Sounds reasonable. What exactly is your intention? Adding the group info to PUBDEFs with given segments that are part of a group?

Yes, exactingly.

[boeckmann]

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.

[ecm-pushbx]

For reference, here's the prior thread where we modified fixupp: #61

[ecm-pushbx]

I will upload a patch later. Still have to test it but it seems to work.

[ecm-pushbx]

https://hg.pushbx.org/ecm/fixupp/rev/7888d52b621a I uploaded it into a separate repo, here.

[boeckmann]

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.

[ecm-pushbx]

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.

[ecm-pushbx]

I took the liberty to quote you in the NASM bz: https://bugzilla.nasm.us/show_bug.cgi?id=3392916#c7

[boeckmann]

@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...

[boeckmann]

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.

[ecm-pushbx]

Can you recreate and quote the error/warning?

[boeckmann]

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...

[boeckmann]

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.