Massive eh_frame bloat in busybox (stripped)

Rich Felker dalias at aerifal.cx
Fri May 11 03:52:12 UTC 2012


On Thu, May 10, 2012 at 08:25:52PM +0200, Joakim Tjernlund wrote:
> > > > hmm, that is annoying. Remind me, is eh_frame ONLY used for
> > > > debugging or is there something more, like backtrace and such?
> > >
> > > It's used for C++ exceptions, which the GCC developers believe should
> > > be in C too... Also for backtrace, but that falls under debugging.
> 
> glibc backtrace() isn't debugging. This function should be useful even
> in stripped progs.

I guess we'll just have to disagree on this one. I can't see any way
that backtrace output could be useful to the user of a program unless
that user is also a developer or someone assisting a developer with
crash log information (which I would call a debugging purpose).

> > And also by pthreads when a thread is cancelled.
> >
> > Also note that if unwinding is needed, the absence of .eh_frame may
> 
> hmm, does C progs need unwinding?

No, C never needs unwinding, and worked perfectly fine for 30 years
without it...

> > crash the program (especially if compiled with -fomit-framepointer).
> 
> uhh, that is no good either. Seems like non debug cases are plenty.

This only happens with pthread cancellation (which is seriously broken
in MANY ways in NPTL) and only because NPTL implements it with C++
exceptions (mainly for the sake of being able to mix it with
exceptions in C++ code; otherwise, the way glibc 2.1 implemented it
with a linked list of function pointers was much lighter-weight and
cleaner).

In any case, this is all getting rather OT, as the whole point was
that _busybox_ has no use for eh_frame.

Rich


More information about the busybox mailing list