* win32-arm-low.c regptr 96 bits stored in 32 bit variable
@ 2018-10-26 22:41 Bill Morgan
2018-10-28 16:47 ` Simon Marchi
0 siblings, 1 reply; 4+ messages in thread
From: Bill Morgan @ 2018-10-26 22:41 UTC (permalink / raw)
To: gdb
Should this static variable ULONG zero be at least 96 bits?
static char *
regptr (CONTEXT* c, int r)
{
if (mappings[r] < 0)
{
static ULONG zero;
/* Always force value to zero, in case the user tried to write
to this register before. */
zero = 0;
return (char *) &zero;
}
else
return (char *) c + mappings[r];
}
reg-arm.dat shows 96 bits for the ones that have mappings[r] == -1
name:arm
xmlarch:arm
expedite:r11,sp,pc
32:r0
32:r1
32:r2
32:r3
32:r4
32:r5
32:r6
32:r7
32:r8
32:r9
32:r10
32:r11
32:r12
32:sp
32:lr
32:pc
96:f0
96:f1
96:f2
96:f3
96:f4
96:f5
96:f6
96:f7
32:fps
32:cpsr
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: win32-arm-low.c regptr 96 bits stored in 32 bit variable
2018-10-26 22:41 win32-arm-low.c regptr 96 bits stored in 32 bit variable Bill Morgan
@ 2018-10-28 16:47 ` Simon Marchi
2018-10-29 13:50 ` Richard Earnshaw (lists)
0 siblings, 1 reply; 4+ messages in thread
From: Simon Marchi @ 2018-10-28 16:47 UTC (permalink / raw)
To: Bill Morgan; +Cc: gdb
On 2018-10-26 18:40, Bill Morgan wrote:
> Should this static variable ULONG zero be at least 96 bits?
>
> static char *
> regptr (CONTEXT* c, int r)
> {
> if (mappings[r] < 0)
> {
> static ULONG zero;
> /* Always force value to zero, in case the user tried to write
> to this register before. */
> zero = 0;
> return (char *) &zero;
> }
> else
> return (char *) c + mappings[r];
> }
>
> reg-arm.dat shows 96 bits for the ones that have mappings[r] == -1
>
> name:arm
> xmlarch:arm
> expedite:r11,sp,pc
> 32:r0
> 32:r1
> 32:r2
> 32:r3
> 32:r4
> 32:r5
> 32:r6
> 32:r7
> 32:r8
> 32:r9
> 32:r10
> 32:r11
> 32:r12
> 32:sp
> 32:lr
> 32:pc
> 96:f0
> 96:f1
> 96:f2
> 96:f3
> 96:f4
> 96:f5
> 96:f6
> 96:f7
> 32:fps
> 32:cpsr
Hi Bill,
By inspection, it does seem like a mistake, and that we would need to
return a pointer to a buffer at least as big as register r. But I have
no idea how to build/run/test gdbserver on win32/arm. If you are able
to confirm that there is a problem and test a fix, could you please
provide a patch?
To avoid this kind of problem again, we could return a pointer to a
dynamically-sized buffer adjusted to the size of the register.
Something like this:
static char *
regptr (CONTEXT* c, struct regcache *regcache, int r)
{
if (mappings[r] < 0)
{
static gdb::byte_vector zero;
/* Always force value to zero, in case the user tried to write
to this register before. */
zero.assign (regcache_register_size (regcache, r), 0);
return (char *) zero.data ();
}
else
return (char *) c + mappings[r];
}
Simon
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: win32-arm-low.c regptr 96 bits stored in 32 bit variable
2018-10-28 16:47 ` Simon Marchi
@ 2018-10-29 13:50 ` Richard Earnshaw (lists)
2018-10-29 15:31 ` Simon Marchi
0 siblings, 1 reply; 4+ messages in thread
From: Richard Earnshaw (lists) @ 2018-10-29 13:50 UTC (permalink / raw)
To: Simon Marchi, Bill Morgan; +Cc: gdb
Surely nobody is interested in the long-dead FPA architecture these
days. I'm not sure why GDB still supports it.
R.
On 28/10/2018 16:47, Simon Marchi wrote:
> On 2018-10-26 18:40, Bill Morgan wrote:
>> Should this static variable ULONG zero be at least 96 bits?
>>
>> static char *
>> regptr (CONTEXT* c, int r)
>> {
>> Â if (mappings[r] < 0)
>> Â {
>> Â Â Â static ULONG zero;
>> Â Â Â /* Always force value to zero, in case the user tried to write
>>       to this register before. */
>> Â Â Â zero = 0;
>> Â Â Â return (char *) &zero;
>> Â }
>> Â else
>> Â Â Â return (char *) c + mappings[r];
>> }
>>
>> reg-arm.dat shows 96 bits for the ones that have mappings[r] == -1
>>
>> name:arm
>> xmlarch:arm
>> expedite:r11,sp,pc
>> 32:r0
>> 32:r1
>> 32:r2
>> 32:r3
>> 32:r4
>> 32:r5
>> 32:r6
>> 32:r7
>> 32:r8
>> 32:r9
>> 32:r10
>> 32:r11
>> 32:r12
>> 32:sp
>> 32:lr
>> 32:pc
>> 96:f0
>> 96:f1
>> 96:f2
>> 96:f3
>> 96:f4
>> 96:f5
>> 96:f6
>> 96:f7
>> 32:fps
>> 32:cpsr
>
> Hi Bill,
>
> By inspection, it does seem like a mistake, and that we would need to
> return a pointer to a buffer at least as big as register r. But I have
> no idea how to build/run/test gdbserver on win32/arm. If you are able
> to confirm that there is a problem and test a fix, could you please
> provide a patch?
>
> To avoid this kind of problem again, we could return a pointer to a
> dynamically-sized buffer adjusted to the size of the register.Â
> Something like this:
>
> static char *
> regptr (CONTEXT* c, struct regcache *regcache, int r)
> {
> Â if (mappings[r] < 0)
> Â {
> Â Â Â static gdb::byte_vector zero;
> Â Â Â /* Always force value to zero, in case the user tried to write
>       to this register before. */
> Â Â Â zero.assign (regcache_register_size (regcache, r), 0);
> Â Â Â return (char *) zero.data ();
> Â }
> Â else
> Â Â Â return (char *) c + mappings[r];
> }
>
> Simon
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: win32-arm-low.c regptr 96 bits stored in 32 bit variable
2018-10-29 13:50 ` Richard Earnshaw (lists)
@ 2018-10-29 15:31 ` Simon Marchi
0 siblings, 0 replies; 4+ messages in thread
From: Simon Marchi @ 2018-10-29 15:31 UTC (permalink / raw)
To: Richard Earnshaw (lists); +Cc: Bill Morgan, gdb
On 2018-10-29 09:50, Richard Earnshaw (lists) wrote:
> Surely nobody is interested in the long-dead FPA architecture these
> days. I'm not sure why GDB still supports it.
If it's really useless to support it today and it's just dead weight, it
would be ideal if somebody from ARM (that has the full picture of the
situation) made a patch to remove it.
Thanks,
Simon
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-10-29 15:31 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-26 22:41 win32-arm-low.c regptr 96 bits stored in 32 bit variable Bill Morgan
2018-10-28 16:47 ` Simon Marchi
2018-10-29 13:50 ` Richard Earnshaw (lists)
2018-10-29 15:31 ` Simon Marchi
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).