Re: Cygport and auto-manifestize compatibility manifest

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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