Re: [PATCH v9] Build process uses script to add CFI directives to x86 asm

[Alex <alexinbeijing@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

>
>
> I think someone mentioned this before -- this still fails to apply CFI
> to the asm files obtained via the .sub/SUBARCH system (see the rules
> just above the ones you changed). Of course I don't really like
> duplicating complex rules, and i386 has no SUBARCHs anyway, so perhaps
> we could put off changing this if someone has an idea for how to
> eliminate the extra rules for SUBARCHs when we overhaul the build
> system...
>

This was intentional, but since it has come up so many times, I will add
the (extraneous) rules for SUBARCHs.


> I'd still like to check $CFLAGS in addition to $CFLAGS_AUTO, since
> CFLAGS=-g is the usual way I ask for debug info. (I'm sorry I ever
> added the --enable-debug option to configure. :)
>

OK, will do.


> I haven't reviewed the awk script much at all, but as long as it seems
> to work in practice I'm okay with committing it. One thing I would
> like to ask though -- is it pretty robust against bad things happening
> if it sees new asm constructs it's not expecting? I'd just like to
> avoid regressions if we add new asm later, where it becomes necessary
> to delay commits to asm in order to fix bugs in the CFI generation.


It passes all your asm through and simply adds debugging directives when it
recognizes certain constructs. So in no case will it actually break the
asm. The worst which will happen is that you will adjust the stack pointer
in some obscure way that it doesn't recognize, no CFI directive will be
added, and then a debugger will be unable to produce a stack trace at that
point in the code. But this is no worse than what we have right now. Right
now we don't do anything to help the debugger at all.

Thanks, AD

[-- Attachment #2: Type: text/html, Size: 2364 bytes --]