support stubs >2K

[jwt27]

support stubs >2K

[jwt27]

As you said this is a binutils issue and not with djgpp itself. But this brings up an interesting point: I don't know where djgpp patches for binutils (or other packages) are developed. As far as I can tell this isn't checked in to source control anywhere. All we get is the zip file from delorie.com with djgpp specific patches already applied.

[stsp]

I can see them in djgpp/* directory.

[jwt27]

Yes those are the patch files. But they're not being developed in any cvs/svn/git repository as far as I can tell. And I don't understand why those patches aren't being merged with binutils upstream. You can build the official binutils release with --target=i*86-pc-msdosdjgpp but then you'll end up with subtly broken things like non-functional ldscripts.

[stsp]

Maybe you can setup the source tree,
review and upstream all the patches. :)

[jwt27]

Someday, maybe. I have enough other stuff to deal with for now.

[jwt27]

The number you'll want to change is #define GO32_STUBSIZE 2048 at binutils-2.33.1/include/coff/internal.h line 61.

It looks like binutils always regards the first 2k bytes to be part of the stub, so changing this number will break compatibility with any executables that have a 2k stub. You'd have to find space for a version byte in the stub somewhere and make binutils determine the stub size based on that.

[jwt27]

Also there's probably a lot of other code out there that expects a fixed stub size, eg. upx and other exe packers.

[stsp]

MZ header should itself contain the
exe size (stub size) and overlay size
(prog itself), so I hope things like upx
etc do not have this all hard-coded.
But I didn't check.

[jwt27]

https://github.com/upx/upx/blob/d7ba31cab8ce8d95d2c10e88d2ec787ac52005ef/src/p_djgpp2.cpp#L198-L205
You're right, upx reads the stub size from the header.

On the binutils side it seems everything is nailed down with #defines.

[stsp]

So at worst case we can lose
compatibility with older binutils.
But this doesn't look like the real
problem.

[jwt27]

I did some hacking last night... haven't tried it yet.
jwt27/binutils-gdb@djgpp-patches...go32stub
If this works then we can have variable length stubs without losing backward compatibility.

[stsp]

What do you need to test that? :)
Well, you can just enlarge the no envseg$
msg. Its quite easy to test I think.

[jwt27]

I took a program with a 2k stub and inserted some bytes before the coff image. objdump seems to work with it. strip crashes in coff_swap_filehdr_out. I think it's because the output filehdr isn't fully allocated.

[jwt27]

Let's move this discussion to jwt27/binutils-gdb#1 where the patches are.