[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#255495: acknowledged by developer (Re: Bug#255495: gcc-snapshot: Keep debugging symbols)



On Sat, Jun 26, 2004 at 07:42:19AM +0200, Matthias Klose wrote:
> Daniel Jacobowitz writes:
> > On Tue, Jun 22, 2004 at 12:51:41PM +0200, Daniel Bonniot wrote:
> > > 
> > > Thanks for your prompt answer.
> > > 
> > > >yes, space & bandwidth. the packages get 100%-200% bigger. and if you
> > > >really want to debug gcc, you need the source and you build it
> > > >yourself. gcc-snapshot is intended to check for bugs in development
> > > >versions of gcc, such that package maintainers can have it installed
> > > >on different architectures.
> > > > 
> > > >
> > > In my case, I don't really want to debug gcc, but I want to make an 
> > > upstream bug report as precise as possible. So including a stack trace 
> > > would be a bonus. It should help narrowing the nature of the bug, so 
> > > that the appriopriate upstream author can start investigating, thus 
> > > saving them time.
> > 
> > Hmm, we could ship it with just unwind (.debug_frame) information and
> > static symbols, but remove .debug_info/.debug_str.  That's what
> > libc6-dbg does now and it's proven useful.
> 
> looks fine. is there an easy way to enumerate all the sections which
> should be stripped?

Not really.  Take a look at debian/wrapper/objcopy and
debian/rules.d/debhelper.mk in the glibc-package CVS:
#!/bin/sh

case " $* " in
  *" --only-keep-debug "*)
    exec /usr/bin/objcopy -R .debug_info -R .debug_aranges -R .debug_pubnames \
        -R .debug_abbrev -R .debug_line -R .debug_str -R .debug_ranges \
        -R .comment -R .note "$@"
    ;;
esac

exec /usr/bin/objcopy "$@"


-- 
Daniel Jacobowitz



Reply to: