This is the mail archive of the cygwin-apps mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Nov 20 18:32, Corinna Vinschen wrote: > On Nov 20 18:22, Achim Gratz wrote: > > Corinna Vinschen writes: > > > Well, perhaps. I'm just not sure it's the right thing to do it at > > > postinstall time. I mean, it's not impossible, obviously, but it's > > > a lot of stuff per executable and running this for a few thousand .exe > > > files could take some time. > > > > Yes, it does... but ever since I've switched to doing incremental > > autorebases that time has shrunk a lot. > > > > > We would also have to make sure that the sections with long section > > > names are recreated after adding the .rsrc section, which is something > > > I don't quite see how to accomplish, right now. > > > > Hmm. I'm out of my depths on this, but would it be possible to excise > > those sections, do whatever changes are necessary to the rest of the > > executable and then add them back? > > I don't know. It's apparently more complicated than just calling > objcopy. For instance, objcopy can export sections from a file in > whatever format you want, but it can only add back sections if they are > given as binary blobs. If you add such a binary blob it's missing > relocation information. Also, you have to make sure all the sections > start at the right address, thanks to the harebrained PE/COFF format. > > This is apparently a big deal, otherwise it should have been no problem > to add a resource binary blob into an executable without making Windows > choke on it (ERROR_BAD_EXE_FORMAT). Maybe I did something wrong, but I > would have no idea what option I missed. I just made a quick test for the sake of creating a generic script to add the manifests. Assuming I have a file with just a single section with long section name, the .gnu_debuglink section. Fortunately this seems to be the usual case. I can extract the section content: $ objcopy -j .gnu_debuglink -O binary foo.exe foo.exe.gdl Then I can drop the .gnu_debuglink from the executable. Create a copy of the original so as not to confuse the sensitive UpdateResource: $ objcopy -R .gnu_debuglink foo.exe foo.out Then I can add the manifest: $ add-cygwin-default-manifest foo.out Then it gets weird. I'd like to create a .gnu_debuglink section again. The path is part of the binary foo.exe.gdl file: $ awk -F \\0 '{print $1;}' foo.dbgl foo.exe.dbg $ objcopy --add-gnu-debuglink=$(awk -F \\0 '{print $1;}' foo.dbgl) foo.out objcopy:stl7AEHg: cannot fill debug link section `foo.exe.dbg': No such file or directory So the dbg file has to exist to be able to create a new .gnu_debuglink section: $ touch $(awk -F \\0 '{print $1;}' foo.dbgl) $ objcopy --add-gnu-debuglink=$(awk -F \\0 '{print $1;}' foo.dbgl) foo.out Cool. That worked, and the resulting executable works as well. But GDB doesn't find the symbol file anymore: $ gdb ./tcsh.out [...] Reading symbols from /home/corinna/manifest/tcsh.out...(no debugging symbols found)...done. (gdb) Quit $ objcopy -j .gnu_debuglink -O binary foo.out foo.out.gdl $ cmp foo.exe.gdl foo.out.gdl foo.exe.gdl foo.out.gdl differ: byte 17, line 1 Why is that? And, if the .gnu_debuglink sections contains only a filename and some flag value or something, why does it suddenly neglect to search in the /usr/lib/debug directory? How can this be fixed? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
pgpUGCfrDAco_.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |