Re: [PATCH] generate debug_frame info for __syscall_cp_asm (i386) so gdb can get backtrace

Re: [PATCH] generate debug_frame info for __syscall_cp_asm (i386) so gdb can get backtrace

[Alex Dowad]

On Wed, 29 Apr 2015 11:57:03 -0400, Rich Felkner wrote:
> It would be either sed or awk most likely. Plain shell would work for
> writing it too but would probably be uglier, and sed is already
> required anyway for alltypes.h generation. If any new tool were
> required (unlikely) then configure would just detect its absence and
> turn off cfi generation for asm if it's missing/broken.

I can try coding up an awk script if you like (no sed, sorry). It will be a
filter which the asm passes through to add the .cfi_* directives. Does that
sound good?

(I really, really hope you weren't looking for an awk/sed script which takes
asm as input and generates a DWARF file as output...)

Regards, AD

Re: Re: [PATCH] generate debug_frame info for __syscall_cp_asm (i386) so gdb can get backtrace

[Rich Felker]

On Wed, Apr 29, 2015 at 06:51:29PM +0200, Alex Dowad wrote:
> On Wed, 29 Apr 2015 11:57:03 -0400, Rich Felkner wrote:
> > It would be either sed or awk most likely. Plain shell would work for
> > writing it too but would probably be uglier, and sed is already
> > required anyway for alltypes.h generation. If any new tool were
> > required (unlikely) then configure would just detect its absence and
> > turn off cfi generation for asm if it's missing/broken.
> 
> I can try coding up an awk script if you like (no sed, sorry). It will be a
> filter which the asm passes through to add the .cfi_* directives. Does that
> sound good?
> 
> (I really, really hope you weren't looking for an awk/sed script which takes
> asm as input and generates a DWARF file as output...)

Of course not; I meant for it to produce asm with cfi directives as
output. If you'd like to give it a try that would be great. Some of
the main criteria that would matter for inclusion in musl would be
portable awk usage (standard awk, not gawk/etc., and compatible with
Busybox) and the ability to support multiple archs -- even if the
initial code is x86-only, it should take $ARCH as an argument and be
reasonably easy for others to extend it to support other archs.

Rich

Re: [PATCH] generate debug_frame info for __syscall_cp_asm (i386) so gdb can get backtrace

[Alex Dowad]

On Mon, 27 Apr 2015 16:57:22 -0400, Rich Felkner wrote:
> This has been requested before, but it really uglifies the asm and
> makes it unreadable. Do you have any ideas for mitigating the problem?

Perhaps using PUSH() and POP() macros which automatically add .cfi_*
directives?

> 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.

Conditionally defining the PUSH() and POP() macros to omit the .cfi_*
stuff when debugging is disabled?

Of course using a script to parse the asm is SO much more slick... but
you probably don't want to add too many dependencies to your build process
either. Would it have to be just a plain shell script?

Thanks for your feedback, AD

Re: [PATCH] generate debug_frame info for __syscall_cp_asm (i386) so gdb can get backtrace

[Rich Felker]

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@libc.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

Re: [PATCH] generate debug_frame info for __syscall_cp_asm (i386) so gdb can get backtrace

[Timo Teras]

On Mon, 27 Apr 2015 16:57:22 -0400
Rich Felker <dalias@libc.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.

I'd at least arm the syscall, and the startup code with manual .cfi
stuff for debugging purposes. If we want to do universal .cfi
annotations for all asm, it'd make sense to have some programmatic way
to generate it.

But I'd really appreciate having usable backtraces.

Thanks,
Timo

Re: [PATCH] generate debug_frame info for __syscall_cp_asm (i386) so gdb can get backtrace

[Rich Felker]

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

[PATCH] generate debug_frame info for __syscall_cp_asm (i386) so gdb can get backtrace

[Alex Dowad]

__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.

By the way, I absolutely and utterly LOVE your Makefile and configure scripts. They're
so... so SANE. I never thought a configure script could make me this happy! Thank you!

Regards,
Alex Dowad <alexinbeijing@gmail.com>

diff --git a/src/thread/i386/syscall_cp.s b/src/thread/i386/syscall_cp.s
index 7dce1eb..baba145 100644
--- a/src/thread/i386/syscall_cp.s
+++ b/src/thread/i386/syscall_cp.s
@@ -9,12 +9,23 @@
 .global __syscall_cp_asm
 .hidden __syscall_cp_asm
 .type   __syscall_cp_asm,@function
+.cfi_sections .debug_frame
+.cfi_startproc
 __syscall_cp_asm:
 	mov 4(%esp),%ecx
 	pushl %ebx
+.cfi_adjust_cfa_offset 4
+.cfi_offset ebx,-8
 	pushl %esi
+.cfi_adjust_cfa_offset 4
+.cfi_offset esi,-12
 	pushl %edi
+.cfi_adjust_cfa_offset 4
+.cfi_offset edi,-16
 	pushl %ebp
+.cfi_adjust_cfa_offset 4
+.cfi_offset ebp,-20
 __cp_begin:
 	movl (%ecx),%eax
 	testl %eax,%eax
@@ -29,10 +40,19 @@ __cp_begin:
 	int $128
 __cp_end:
 	popl %ebp
+.cfi_adjust_cfa_offset -4
+.cfi_restore ebp
 	popl %edi
+.cfi_adjust_cfa_offset -4
+.cfi_restore edi
 	popl %esi
+.cfi_adjust_cfa_offset -4
+.cfi_restore esi
 	popl %ebx
+.cfi_adjust_cfa_offset -4
+.cfi_restore ebx
 	ret
+.cfi_endproc
 __cp_cancel:
 	popl %ebp
 	popl %edi
-- 
2.0.0.GIT