From: "Andreas Färber" <afaerber@suse.de>
To: "Benoît Canet" <benoit.canet@gmail.com>
Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] arm-linux-user: fix elfload.c's AT_HWCAP reflected cpu features.
Date: Wed, 09 Nov 2011 14:34:41 +0100 [thread overview]
Message-ID: <4EBA8171.50505@suse.de> (raw)
In-Reply-To: <1320843872-2402-2-git-send-email-benoit.canet@gmail.com>
Am 09.11.2011 14:04, schrieb Benoît Canet:
> The cpu capabilities passed by the elf loader in AT_HWCAP where
> a constant.
> Make AT_HWCAP reflect the emulated cpu features in order to give
> correct clues to eglibc.
>
> Fix : [Bug 887516] [NEW] VFP support reported for the PXA270
>
> Signed-off-by: Benoit Canet <benoit.canet@gmail.com>
> ---
> linux-user/elfload.c | 31 +++++++++++++++++++++++++++----
> 1 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/linux-user/elfload.c b/linux-user/elfload.c
> index a413976..5d81ec1 100644
> --- a/linux-user/elfload.c
> +++ b/linux-user/elfload.c
> @@ -375,10 +375,33 @@ bool guest_validate_base(unsigned long guest_base)
> return 1; /* All good */
> }
>
> -#define ELF_HWCAP (ARM_HWCAP_ARM_SWP | ARM_HWCAP_ARM_HALF \
> - | ARM_HWCAP_ARM_THUMB | ARM_HWCAP_ARM_FAST_MULT \
> - | ARM_HWCAP_ARM_FPA | ARM_HWCAP_ARM_VFP \
> - | ARM_HWCAP_ARM_NEON | ARM_HWCAP_ARM_VFPv3 )
> +
> +#define ELF_HWCAP get_elf_hwcap()
I assume ELF_HWCAP is being used in architecture-independent code? Or
would it be feasible to replace all occurrences with the function call?
> +
> +static uint32_t get_elf_hwcap(void)
> +{
> + CPUState *e = thread_env;
> + uint32_t hwcaps = 0;
> +
> + hwcaps |= ARM_HWCAP_ARM_SWP;
> + hwcaps |= ARM_HWCAP_ARM_HALF;
> + hwcaps |= ARM_HWCAP_ARM_THUMB;
> + hwcaps |= ARM_HWCAP_ARM_FAST_MULT;
> + hwcaps |= ARM_HWCAP_ARM_FPA;
> +
> + /* prove for the extra features */
probe?
> +#define GET_FEATURE(feat, hwcap) \
> + do {if (arm_feature(e, feat)) { hwcaps |= hwcap; } } while (0)
This doesn't return anything, it sets the hwcap flag. SET_HWCAP maybe?
> + GET_FEATURE(ARM_FEATURE_VFP, ARM_HWCAP_ARM_VFP);
> + GET_FEATURE(ARM_FEATURE_IWMMXT, ARM_HWCAP_ARM_IWMMXT);
> + GET_FEATURE(ARM_FEATURE_THUMB2EE, ARM_HWCAP_ARM_THUMBEE);
> + GET_FEATURE(ARM_FEATURE_NEON, ARM_HWCAP_ARM_NEON);
> + GET_FEATURE(ARM_FEATURE_VFP3, ARM_HWCAP_ARM_VFPv3);
> + GET_FEATURE(ARM_FEATURE_VFP_FP16, ARM_HWCAP_ARM_VFPv3D16);
I'm wondering if this translation table were better placed in
target-arm/helper.c where we fiddle with the features in the first
place. We could loop through all features here and call a function that
returns the hwcap or 0 and |= it. Me and others will be adding new
features and we'll risk adapting this here.
I was told that VFP_FP16 is *not* VFPv3-D16. Please remove that for now.
> +#undef GET_FEATURE
> +
> + return hwcaps;
> +}
>
> #endif
>
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2011-11-09 13:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-09 13:04 [Qemu-devel] [PATCH] Fix : [Bug 887516] [NEW] VFP support reported for the PXA270 Benoît Canet
2011-11-09 13:04 ` [Qemu-devel] [PATCH] arm-linux-user: fix elfload.c's AT_HWCAP reflected cpu features Benoît Canet
2011-11-09 13:34 ` Andreas Färber [this message]
2011-11-09 13:51 ` Benoît Canet
2011-11-09 14:06 ` Peter Maydell
2011-11-09 14:41 ` Andreas Färber
2011-11-09 14:01 ` Peter Maydell
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=4EBA8171.50505@suse.de \
--to=afaerber@suse.de \
--cc=benoit.canet@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.