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 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: Re: [PATCH] generate debug_frame info for __syscall_cp_asm (i386) so gdb can get backtrace

[Rich Felker]

On Wed, Apr 29, 2015 at 04:46:18PM +0200, Alex Dowad wrote:
> 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?

The reason I don't like solutions like this is that anyone reading the
code immediately wonders what those macros are and whether there is
important functionality hidden in them that's obscuring what the code
is doing. I know that's my first thought when I see asm (or C) written
like that.

Also this is rather x86-specific; many other archs don't have/use
push/pop instructions.

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

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.

Rich

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