[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150417164401.GY6817@brightrain.aerifal.cx>
Date: Fri, 17 Apr 2015 12:44:01 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] replace 'hlt' by 'ud2' in i386/x32/x86_64 a_crash
implementations
On Fri, Apr 17, 2015 at 11:12:20AM +0300, Alexander Monakov wrote:
> On Fri, 17 Apr 2015, Rich Felker wrote:
>
> > On Thu, Apr 16, 2015 at 08:58:59PM +0300, Alexander Monakov wrote:
> > > ---
> > > ud2 is also what GCC and Clang use to implement __builtin_trap()
> > >
> > > ud2 causes SIGILL rather than SIGSEGV; SIGSEGV is more likely to have a custom
> > > signal handler installed
> >
> > I've pondered instead using:
> >
> > push $-1
> > mov $175,%eax
> > xor %ebx,%ebx
> > mov %esp,%ecx
> > int $128
> > hlt // or ud2?
> >
> > This should be uncatchable but it's moderately larger.
>
> An argument in favor of plain hlt/ud2 is that registers and memory are
> preserved, in case someone will be analyzing the coredump.
That's a good point. The above could be fixed to preserve registers
with some minor added push/pop (simple pusha/popa on 32-bit)
before/after the syscall, but then it gets bigger.
Short of doing something like that, I think it's something of a flip
which of SIGSEGV vs SIGILL is better, and I don't feel like we have
enough information to make a good decision. There are reasons either
could be trapped -- some programs probably trap SIGILL to do runtime
cpudetection nonsense, and some programs just trap all fatal signals
to try to 'cleanup' or save state at exit. I'm not opposed to changing
to ud2 if it's better but I'd like to feel confident that it is better
rather than just guessing. Right now the main argument for ud2 is just
consistency with gcc (which isn't a bad reason in itself, but not very
strong either).
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.
