Patchwork linux-user: avoid gcc array overrun warning for sparc

login
register
mail settings
Submitter Peter Maydell
Date Feb. 1, 2011, 3:54 p.m.
Message ID <1296575692-23335-1-git-send-email-peter.maydell@linaro.org>
Download mbox | patch
Permalink /patch/81332/
State New
Headers show

Comments

Peter Maydell - Feb. 1, 2011, 3:54 p.m.
Suppress a gcc array bounds overrun warning when filling in the SPARC
signal frame by adjusting our definition of the structure so that the
fp and callers_pc membes are part of the ins[] array rather than
separate fields; since qemu has no need to access the fields individually
there is no need to follow the kernel's structure field naming exactly.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
This is a fix for another warning that the armel gcc gives:
linux-user/signal.c:1979: error: array subscript is above array bounds
so if it passes review I think it's a good candidate for putting in 0.14.

 linux-user/signal.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)
Peter Maydell - Feb. 1, 2011, 4 p.m.
On 1 February 2011 15:54, Peter Maydell <peter.maydell@linaro.org> wrote:
> --- a/linux-user/signal.c
> +++ b/linux-user/signal.c
> @@ -1817,9 +1817,10 @@ struct target_sigcontext {
>  /* A Sparc stack frame */
>  struct sparc_stackf {
>         abi_ulong locals[8];
> -        abi_ulong ins[6];
> -        struct sparc_stackf *fp;
> -        abi_ulong callers_pc;
> +        abi_ulong ins[8];
> +        /* It's simpler to treat fp and callers_pc as elements of ins[]
> +         * since we never need to access them ourselves.
> +         */
>         char *structptr;

Incidentally, I think the presence of a host pointer in a target
structure definition is a (different) bug which might cause problems
when the target and host have different pointer sizes...

-- PMM
Blue Swirl - Feb. 1, 2011, 5:58 p.m.
Thanks, applied.

On Tue, Feb 1, 2011 at 3:54 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> Suppress a gcc array bounds overrun warning when filling in the SPARC
> signal frame by adjusting our definition of the structure so that the
> fp and callers_pc membes are part of the ins[] array rather than
> separate fields; since qemu has no need to access the fields individually
> there is no need to follow the kernel's structure field naming exactly.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> This is a fix for another warning that the armel gcc gives:
> linux-user/signal.c:1979: error: array subscript is above array bounds
> so if it passes review I think it's a good candidate for putting in 0.14.
>
>  linux-user/signal.c |    7 ++++---
>  1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/linux-user/signal.c b/linux-user/signal.c
> index 0664770..b01bd64 100644
> --- a/linux-user/signal.c
> +++ b/linux-user/signal.c
> @@ -1817,9 +1817,10 @@ struct target_sigcontext {
>  /* A Sparc stack frame */
>  struct sparc_stackf {
>         abi_ulong locals[8];
> -        abi_ulong ins[6];
> -        struct sparc_stackf *fp;
> -        abi_ulong callers_pc;
> +        abi_ulong ins[8];
> +        /* It's simpler to treat fp and callers_pc as elements of ins[]
> +         * since we never need to access them ourselves.
> +         */
>         char *structptr;
>         abi_ulong xargs[6];
>         abi_ulong xxargs[1];
> --
> 1.7.1
>
>
Blue Swirl - Feb. 1, 2011, 6:02 p.m.
On Tue, Feb 1, 2011 at 4:00 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 1 February 2011 15:54, Peter Maydell <peter.maydell@linaro.org> wrote:
>> --- a/linux-user/signal.c
>> +++ b/linux-user/signal.c
>> @@ -1817,9 +1817,10 @@ struct target_sigcontext {
>>  /* A Sparc stack frame */
>>  struct sparc_stackf {
>>         abi_ulong locals[8];
>> -        abi_ulong ins[6];
>> -        struct sparc_stackf *fp;
>> -        abi_ulong callers_pc;
>> +        abi_ulong ins[8];
>> +        /* It's simpler to treat fp and callers_pc as elements of ins[]
>> +         * since we never need to access them ourselves.
>> +         */
>>         char *structptr;
>
> Incidentally, I think the presence of a host pointer in a target
> structure definition is a (different) bug which might cause problems
> when the target and host have different pointer sizes...

Right, it was copied from Linux. I can't see where it was used.
UREG_FP use cases look OK.

Patch

diff --git a/linux-user/signal.c b/linux-user/signal.c
index 0664770..b01bd64 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -1817,9 +1817,10 @@  struct target_sigcontext {
 /* A Sparc stack frame */
 struct sparc_stackf {
         abi_ulong locals[8];
-        abi_ulong ins[6];
-        struct sparc_stackf *fp;
-        abi_ulong callers_pc;
+        abi_ulong ins[8];
+        /* It's simpler to treat fp and callers_pc as elements of ins[]
+         * since we never need to access them ourselves.
+         */
         char *structptr;
         abi_ulong xargs[6];
         abi_ulong xxargs[1];