ld seems to have an old PE stub

[stsp]

Hi.

I wasn't yet successful in creating PE executable with raw binutils (rather than with djgpp), but, unless I am mistaken, ld still embeds the old stub (the one w/o my patches). Only stubify tool has the new stub, so when using djgpp, the stub is good. But I believe creating PE with raw binutils will yield the old stub. I looked into an ld binary and I can see the old stub there because the error msg that I added, is not there.

How does ld embed the PE stub? Is it hard-coded somewhere in the sources? I mean, the one doesn't build djgpp libc when building the raw binutils. But the stub is there.

[jwt27]

Yup, same as cwsdpmi.

[stsp]

To align to an arbitrary boundary, there is .balign.

OK, lets say its too difficult to port the stub to gas. :) djasm also links the file and produces the full-blown realmode executable in one go. With gas I can only create the stub itself and if I link it with ld, then it will add its own stub... So the best I can do is to try ia16-ld, but then its not any better than djasm.

[stsp]

Or maybe @tkchia will upstream his new linker target? :)

[stsp]

Yup, same as cwsdpmi.

So do you rename hdpmi into cwsdpmi? How does this stub ever execute hdpmi?

[jwt27]

Renaming is one option, or you can use stubedit to set the dpmi host.

[stsp]

In that case I would suggest to add the proper hdpmi support, so that the stub try to execute it before trying cwsdpmi. And ignore the retcode only for hdpmi case. I do not think you can present the situation where you edited the stub, as a bug that needs fixing. Or you can use some env var for specifying DPMI host, and have a retcode quirk if the host is set to be hdpmi. Of course since I am not even subscribed to djgpp list, my opinion about any patches there, can be ignored.

[jwt27]

Adding such specific workarounds would significantly increase the stub size. The patch I submitted is a more universal solution, and it even saves a few bytes.

Even better would be to make hdpmi32 just return 0 on success. I did raise the issue with Japheth, but he doesn't remember what the purpose of the exit status was - so I don't know yet if anything would break if it were changed.

[stsp]

Not a specific work-arounds, but rather a support for other DPMI hosts. If various hosts are supported, then you could claim a bug is there because hdpmi is not working right. Currently its just not a bug. I think having a variable to define a DPMI server would be good, and use cwsdpmi as a fall-back. Then how to fix that particular problem with hdpmi (which currently doesn't exist!) should be thought again. Maybe for example ignore retcode from any non-default DPMI server (the one specified via an env).

[jwt27]

The stub already supports loading "non-standard" dpmi hosts - you can set it via stubedit. How is that different from using an environment var?

[stsp]

Indeed, they seem to prefer the use of stubedit for specifying many things, instead of using env vars...

[stsp]

Hi!

https://github.com/stsp/djstub I pushed the initial version of a new stub that is free from djasm. Its fully functional as far as I can tell, though my "test-suite" is not that big. But I do not suppose you are going to be interested in that work. In fact, I am secretly trying to re-implement the entire toolchain, and this is just the first component that works already. Others will follow... sometime. Or not. :)