search

jwt27 / djgpp-cvs

git mirror of cvs.delorie.com:/cvs/djgpp
http://www.delorie.com/djgpp/cvs.html
GNU General Public License v2.0
10 stars 7 forks source link

support stubs >2K #3

Closed stsp closed 4 years ago

stsp commented 4 years ago

Currently the stub size is limited to 2K, and https://github.com/jwt27/djgpp-cvs/commit/da81e265d6dd79004f2fccc20f302e82b3789f37 sucks the last bytes of it. DJ have confirmed to me that there is no hard limit, and in fact, if you enlarge the msg in the aforementioned patch, things will still work. But, for example, strip will fail to recognize the executable format. So there are just a few bugs on a binutils side to fix, and the large stub will work.

jwt27 commented 4 years ago

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 commented 4 years ago

I can see them in djgpp/* directory.

jwt27 commented 4 years ago

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 commented 4 years ago

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

jwt27 commented 4 years ago

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

jwt27 commented 4 years ago

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 commented 4 years ago

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

stsp commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

jwt27 commented 4 years ago

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

stsp commented 4 years ago

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

jwt27 commented 4 years ago

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 commented 4 years ago

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