From: Peter Maydell <peter.maydell@linaro.org>
To: Christophe Lyon <christophe.lyon@st.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
Christophe Lyon <christophe.lyon@linaro.org>,
Riku Voipio <riku.voipio@iki.fi>,
Laurent Vivier <laurent@vivier.eu>
Subject: Re: [Qemu-devel] [ARM/FDPIC v2 4/4] linux-user: ARM-FDPIC: Add support for signals for FDPIC targets
Date: Mon, 23 Apr 2018 16:31:11 +0100 [thread overview]
Message-ID: <CAFEAcA8L7n4vrdfe2GL9ASpFLiPdsDs+KfgbAYpacNMQuFHp7w@mail.gmail.com> (raw)
In-Reply-To: <e749ca16-26bc-b900-d6b3-a06007e6d572@st.com>
On 23 April 2018 at 15:22, Christophe Lyon <christophe.lyon@st.com> wrote:
> On 23/04/2018 15:05, Peter Maydell wrote:
>>
>> On 23 April 2018 at 08:51, Christophe Lyon <christophe.lyon@st.com> wrote:
>>> @@ -2149,7 +2164,21 @@ setup_return(CPUARMState *env, struct
>>> target_sigaction *ka,
>>> {
>>> abi_ulong handler = ka->_sa_handler;
>>> abi_ulong retcode;
>>> - int thumb = handler & 1;
>>> + abi_ulong funcdesc_ptr = 0;
>>> +
>>> + int thumb;
>>> + int is_fdpic = ((TaskState *)thread_cpu->opaque)->is_fdpic;
>>> +
>>> + if (is_fdpic) {
>>> + /* In FDPIC mode, ka->_sa_handler points to a function
>>> + * descriptor (FD). The first word contains the address of the
>>> + * handler. The second word contains the value of the PIC
>>> + * register (r9). */
>>> + funcdesc_ptr = ka->_sa_handler;
>>
>>
>> You already have ka->_sa_handler in the 'handler' local, so you
>> can just use that.
>>
> OK, I thought it was clearer to use a different name.
The other way to structure that would be to put
handler = ka->_sa_handler;
in an else clause of this if ().
>>> + get_user_ual(handler, funcdesc_ptr);
>>
>>
>> You need to check whether get_user_ual() returned non-zero
>> (indicating that the descriptor isn't readable) and handle that.
>>
> Ha... I feared that :)
> I noticed that quite a lot of get_user_XXX() calls do not
> check the returned value, and since this patch changes
> void setup_return(), I'm not sure what to do in case of
> read error? Call abort() or is there a global flag
> for this purpose, that I should set and which would
> be checked by the caller?
You need to:
* make setup_return() return an error indication
(other code in this file seems to follow the kernel's
example and have this be a return value that's true on
an error and false otherwise)
* have the callers check the error indication, and
if there was an error do:
- unlock the user struct
- call force_sigsegv()
All the callers already have code for doing force_sigsegv,
though they don't yet have a codepath that handles doing
the unlock first. You should be able to just put in
the call to unlock_user_struct(frame, ...) at the existing 'sigsegv:'
labels, because that is guaranteed to be safe on a NULL
host pointer, which is what you'll get in the other
code paths that go to that label. Then you can have
the error check be
if (setup_return(...)) {
goto sigsegv;
}
thanks
-- PMM
prev parent reply other threads:[~2018-04-23 15:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-23 7:51 [Qemu-devel] [ARM/FDPIC v2 0/4] FDPIC ABI for ARM Christophe Lyon
2018-04-23 7:51 ` [Qemu-devel] [ARM/FDPIC v2 1/4] Remove CONFIG_USE_FDPIC Christophe Lyon
2018-04-23 12:23 ` Peter Maydell
2018-04-23 7:51 ` [Qemu-devel] [ARM/FDPIC v2 2/4] linux-user: ARM-FDPIC: Identify ARM FDPIC binaries Christophe Lyon
2018-04-23 12:17 ` Peter Maydell
2018-04-23 12:53 ` Christophe Lyon
2018-04-23 13:26 ` Peter Maydell
2018-04-23 7:51 ` [Qemu-devel] [ARM/FDPIC v2 3/4] linux-user: ARM-FDPIC: Add support of FDPIC for ARM Christophe Lyon
2018-04-23 12:49 ` Peter Maydell
2018-04-23 14:13 ` Christophe Lyon
2018-04-23 15:13 ` Peter Maydell
2018-04-23 7:51 ` [Qemu-devel] [ARM/FDPIC v2 4/4] linux-user: ARM-FDPIC: Add support for signals for FDPIC targets Christophe Lyon
2018-04-23 13:05 ` Peter Maydell
2018-04-23 14:22 ` Christophe Lyon
2018-04-23 15:31 ` Peter Maydell [this message]
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=CAFEAcA8L7n4vrdfe2GL9ASpFLiPdsDs+KfgbAYpacNMQuFHp7w@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=christophe.lyon@linaro.org \
--cc=christophe.lyon@st.com \
--cc=laurent@vivier.eu \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
/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 NNTP newsgroup(s).