[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150429132355.GU17573@brightrain.aerifal.cx>
Date: Wed, 29 Apr 2015 09:23:55 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] generate debug_frame info for __syscall_cp_asm
(i386) so gdb can get backtrace
On Wed, Apr 29, 2015 at 10:46:41AM +0300, Timo Teras wrote:
> On Mon, 27 Apr 2015 16:57:22 -0400
> Rich Felker <dalias@...c.org> wrote:
>
> > On Mon, Apr 27, 2015 at 01:32:35PM +0200, Alex Dowad wrote:
> > > Please have a look at this patch, and CC me on any discussion.
> > > (I've never worked on musl before and haven't joined the mailing
> > > list.) Your feedback will be appreciated. (Just to let you know, I
> > > have build-tested this code and tried it in gdb.)
> > >
> > > If you would like to add similar stack frame debug information to
> > > other asm functions, I would be happy to send more patches. The CFI
> > > directives can be made more concise using asm macros if desired.
> >
> > This has been requested before, but it really uglifies the asm and
> > makes it unreadable. Do you have any ideas for mitigating the problem?
> >
> > One possibility would be omitting instruction-grained cfi and just
> > having enough to produce meaningful information when blocked at the
> > syscall. That's what's actually going to matter in practice for
> > debugging. But that's not very elegant.
> >
> > Another idea would be programmatically generating the cfi from the asm
> > with a script that runs at compile-time, and passing the output of the
> > script to the assembler. One benefit of this approach is that it could
> > be tuned based on whether -g is in use or not. With hard-coded .cfi_*
> > I don't see a clear way to suppress it when -g is not in use.
>
> ..cfi_sections directive can be used to say if it should go
> to .eh_frame, .debug_frame or both. Tuning that right, strip should be
> able to get rid of the excess baggage.
Yes but requiring strip as part of the build process is an additional
pain (e.g. it complicates cross compiling since you can't just set
$CC) and it shouldn't be necessary. What I want, but can't find, is a
way to avoid generating the sections in the .o file unless requested
(and to get it in the right section, in case anyone ever does have a
reason for putting it in .eh_frame).
> I'd at least arm the syscall, and the startup code with manual .cfi
> stuff for debugging purposes.
Is there a reason for startup code? Generally the intent is that the
backtrace stop before that. Maybe the code should be changed to set
the return address stack-slot/register to zero then jump rather than
doing a call to be consistent with this intent if it's not already?
> If we want to do universal .cfi
> annotations for all asm, it'd make sense to have some programmatic way
> to generate it.
Well I just think doing it that way would avoid all the uglification
issues and let us control whether, and in what section, it's output.
Having it in all asm files is just a bonus then.
As to how to make it works, it looks to me like a whole file can
probably be one .cfi_startproc/endproc even if it's multiple
functions, and push/pop/stack-adjustment merely need to generate
.cfi_adjust_cfa_offset (and optionally .cfi_offset to help the
debugger find call-saved registers). I suspect a simple sed script
could do this...
> But I'd really appreciate having usable backtraces.
For me they have always been usable, at least in some minimal sense,
on i386. Somehow gdb figures out what's going on anyway. But I agree
this should be improved.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
