[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Apr 2015 16:57:22 -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 Mon, Apr 27, 2015 at 01:32:35PM +0200, Alex Dowad wrote:
> __syscall_cp_asm needs to use EBP to pass the 6th argument to syscalls with
> 6 arguments, so it can't use it for a frame pointer. Without frame pointers,
> GDB can only show backtraces if it gets CFI information from a .debug_frame
> or .eh_frame section.
>
> GCC automatically generates .debug_frame info for all the functions implemented
> in C, so GDB can get backtraces for them. But the assembler can't generate
> ..debug_frame info for functions implemented in asm, unless you tell it how to
> find the call frame.
>
> With no backtraces, GDB's "catch syscall" is almost useless for syscalls which
> are implemented using syscall_cp, like close and writev. Adding the CFI info makes
> it possible to catch these syscalls and find out exactly where a program is using
> them from.
> ---
> src/thread/i386/syscall_cp.s | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> Dear musl devs,
>
> 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.
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.
