[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150621050547.GC1173@brightrain.aerifal.cx>
Date: Sun, 21 Jun 2015 01:05:47 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH v9] Build process uses script to add CFI
directives to x86 asm
On Sun, Jun 21, 2015 at 07:00:57AM +0200, Alex wrote:
> >
> >
> > 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.
Would doing it with a new AS_CMD variable work and make sense? That
would also eliminate the duplication in logic for .o vs .lo too, I
think...
> > 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.
Thanks!
> > 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.
Alright, sounds good. If all the build system integration issues are
worked out then I think this will be ready to commit.
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.
