Cygport and auto-manifestize compatibility manifest
Corinna Vinschen
corinna-cygwin@cygwin.com
Wed Nov 20 18:15:00 GMT 2013
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20131120/f8edf4b5/attachment.sig>
More information about the Cygwin-apps
mailing list