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