[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160126233231.GO9621@port70.net>
Date: Wed, 27 Jan 2016 00:32:32 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Separate siginfo_t for MIPS
* Rich Felker <dalias@...c.org> [2016-01-26 17:57:57 -0500]:
> On Tue, Jan 26, 2016 at 11:24:54PM +0100, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@...c.org> [2015-12-15 23:34:28 -0500]:
> > > On Thu, Dec 10, 2015 at 01:36:33PM +0100, Szabolcs Nagy wrote:
> > > > * Dmitry Ivanov <dmitrijs.ivanovs@...t.com> [2015-12-10 12:47:12 +0200]:
> > > > > MIPS has non-default siginfo_t structure. Also, some si_code values are
> > > > > different. This patch is required for POSIX timers to work.
> > ....
> > > > until then i think it's enough to fix it in signal.h
> > > > with some dirty ifdef around these members.
> > >
> > > Indeed, I think a makeshift solution could work okay here and avoid
> > > moving this large, redundant structure into bits/signal.h. However I'd
> > > rather not depend on compiler-predefined macros (like __mips__ in
> > > Dmitry's second patch) in public headers, since we don't assume
> > > particular compilers for compiling applications.
> > >
> > > Ideally bits/signal.h would define something in the reserved namespace
> > > to change the behavior of the top-level signal.h. However
> > > bits/signal.h needs to be towards the bottom of signal.h for other
> > > reasons, so I don't see a really clean solution. Ideas?
> >
> > workaround solution attached, only build tested
>
> Why not just:
>
> > diff --git a/arch/mips/bits/signal.h b/arch/mips/bits/signal.h
> > index 818e0a7..50a0061 100644
> > --- a/arch/mips/bits/signal.h
> > +++ b/arch/mips/bits/signal.h
> > @@ -73,6 +73,18 @@ typedef struct __ucontext {
> > #define SIG_UNBLOCK 2
> > #define SIG_SETMASK 3
> >
> > +#undef SI_ASYNCIO
> > +#undef SI_MESGQ
> > +#undef SI_TIMER
> > +#define SI_ASYNCIO (-2)
> > +#define SI_MESGQ (-4)
> > +#define SI_TIMER (-3)
> > +
> > +#undef si_errno
> > +#undef si_code
> > +#define si_errno __si_code
> > +#define si_code __si_errno
>
> #define si_errno si_code
> #define si_code si_errno
true, that's better
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.
