From: Rich Felker <dalias@libc.org>
To: Ian Lance Taylor <iant@golang.org>
Cc: soeren@soeren-tempel.net, gcc-patches@gcc.gnu.org,
gofrontend-dev@googlegroups.com, schwab@linux-m68k.org
Subject: Re: [PATCH v3] libgo: Don't use pt_regs member in mcontext_t
Date: Tue, 8 Mar 2022 08:23:58 -0500 [thread overview]
Message-ID: <20220308132357.GN7074@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAOyqgcW3Q=cjdBF=oRZ81hbDyijBMnW7cdDP6gEB42ddDaFcWg@mail.gmail.com>
On Mon, Mar 07, 2022 at 02:59:02PM -0800, Ian Lance Taylor wrote:
> On Sun, Mar 6, 2022 at 11:11 PM <soeren@soeren-tempel.net> wrote:
> >
> > +#ifdef __PPC64__
> > + ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.gp_regs[32];
> > +#else
> > + ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.gregs[32];
> > +#endif
>
> Have you tested this in 32-bit mode? It does not look correct based
> on the glibc definitions. Looking at glibc it seems that it ought to
> be
>
> reg.sigpc = ((ucontext_t*)(context))->uc_mcontext.uc_regs->gregs[32];
Indeed, I think it has to use that conditional on __GLIBC__. I was
thinking the union glibc has was an anon union, but no, it's named
uc_mcontext despite not having type mcontext_t.
Ideally glibc could fix this by doing:
union {
union __ctx(uc_regs_ptr) {
struct __ctx(pt_regs) *__ctx(regs);
mcontext_t *__ctx(uc_regs);
} uc_mcontext;
mcontext_t *__ctx(uc_regs);
};
so that there would be a common API for accessing it that doesn't
conflict with the properties the standard mandates.
Rich
next prev parent reply other threads:[~2022-03-08 13:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-02 16:37 [PATCH] libgo: include asm/ptrace.h for pt_regs definition on PowerPC soeren
2022-02-20 10:43 ` Sören Tempel
2022-02-21 17:25 ` [gofrontend-dev] " Ian Lance Taylor
2022-03-06 12:49 ` Sören Tempel
2022-03-06 15:22 ` Rich Felker
2022-03-06 16:59 ` Rich Felker
2022-02-20 11:01 ` Andreas Schwab
2022-03-06 18:59 ` [PATCH v2] libgo: Don't use pt_regs member in mcontext_t soeren
2022-03-06 21:21 ` Rich Felker
2022-03-07 7:09 ` [PATCH v3] " soeren
2022-03-07 22:59 ` Ian Lance Taylor
2022-03-08 13:23 ` Rich Felker [this message]
2022-03-09 7:26 ` Sören Tempel
2022-03-09 11:52 ` Rich Felker
2022-03-11 7:34 ` [PATCH v4] " soeren
2022-03-31 16:41 ` Sören Tempel
2022-03-31 20:26 ` Ian Lance Taylor
2022-04-02 8:21 ` Sören Tempel
2022-04-03 2:02 ` Ian Lance Taylor
2022-04-03 9:28 ` Sören Tempel
2022-04-11 17:25 ` Sören Tempel
2022-04-11 17:35 ` Ian Lance Taylor
2022-04-11 18:28 ` Sören Tempel
2022-04-14 22:15 ` Ian Lance Taylor
2022-04-21 0:50 ` Ian Lance Taylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220308132357.GN7074@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=gofrontend-dev@googlegroups.com \
--cc=iant@golang.org \
--cc=schwab@linux-m68k.org \
--cc=soeren@soeren-tempel.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).