[RFC] cygport: split debuginfo packages

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Jun 22 09:51:00 GMT 2012

On Jun 21 14:47, Yaakov (Cygwin/X) wrote:
> On 2012-06-21 04:03, Corinna Vinschen wrote:
> >On Jun 21 01:24, Yaakov (Cygwin/X) wrote:
> >>3) Sources referenced by the .dbg files are placed under
> >>/usr/src/debug/${PF}, as indicated by the -fdebug-prefix-map flags.
> >
> >I don't quite understand that.  The sources are not part of the
> >debuginfo package.  And usually you'd want to reference the sources
> >from your builds.  Wouldn't /usr/src/${PVR}/src make more sense?
> Fedora -debuginfo packages include referenced sources in a > package-specific subdir of /usr/src/debug.  There are several
> reasons for this:
> * packages may be built anywhere on the system (a single location is
> required to be useful by all);
> * relying on -src means -debuginfo isn't usable by itself (requires
> an extra installation step);
> * sources generated during the build won't be found (this is why
> __prepdebugsrc checks in $B as well as $S for sources).
> It seems RPM solves this dilemma by changing the encoded
> debug-prefix-map on the fly[1], but that program is ELF-specific.

Hmm, too bad.  In theory it should be possible to tweak the tool to work
on PE-COFF files as well.  After all, we also use Dwarf2 debug
information, so the core of the application is the same.  Just the way
how to read and write the sections has to be changed.  Could be a bit
tricky, though.

> >>Unfortunately, this breaks in-tree debugging (e.g. a noinst test or
> >>sample application).  AFAICS, binutils doesn't support changing the
> >>debug-prefix-map after the fact.  Does anyone have any suggestions
> >>on how to handle this?

Just an idle idea.  What if the compile step omits -fdebug-prefix-map,
and the install step rebuilds the binaries with -fdebug-prefix-map?
Could take quite a while on big packages, though...

> >Well, there's the "dir" command on the GDB command line...
> That is a pain, as all but the smallest packages have sources in
> more than one (sub)directory.  But now that you mention it,
> substitute-path would be a feasible solution in most cases.
> So the question is, are package maintainers okay with an additional
> directory or substitute-path for in-tree debugging, or can we find
> an equivalent to RPM's debugedit?

Or, what about this?  Always build with -fdebug-prefix-map, but also
add a .gdbinit file to the bin directory which sets the search directories
accordingly for the local debugging of the maintainer?  GDB itself does the
same to enable to debug the just built GDB with the system GDB.

> >>4) The resulting binaries are somewhat larger, having only been
> >>--strip-debug'ed; what more is lost by --strip-unneeded or
> >>--strip-all to justify the larger binaries?
> >
> >I don't know.  Did you look with objdump -h what the difference is?
> There is no difference in objdump -h output between the results of
> any of the --strip-* options, but the file sizes definitely change,
> e.g.:
> unstripped        4766253 bytes
> split .dbg file   3765748
> --strip-debug     1479875
> --strip-unneeded  1069624
> --strip-all       1024014
> (This is before --add-gnu-debuglink, which adds 527 bytes.)
> Unfortunately, the manpages aren't clear; what exactly is meant by
> "symbols needed for relocation processing" and "[non-debugging]
> symbols that are not needed for relocation processing"?

I have no idea, sorry.  WHy don't you just call strip without option?
This always worked so far, afaics.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-apps mailing list