* Re: gdbserver on sh4
2009-03-31 8:23 gdbserver on sh4 Michael Trimarchi
@ 2009-03-31 8:52 ` Paul Mundt
2009-03-31 9:02 ` Michael Trimarchi
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Paul Mundt @ 2009-03-31 8:52 UTC (permalink / raw)
To: linux-sh
On Tue, Mar 31, 2009 at 10:23:18AM +0200, Michael Trimarchi wrote:
> binom wrote:
> >Dear michael ,
> >In your reply message it's written that "I fix this problem".
> >Can you pl explain what was the problem and and which is the components to
> >be updated for incorporating this fix?
> >Below given is the details of the host side GDB and target side gdbserver.
> > sh4-linux-gdb --version
> >GNU gdb STMicroelectronics/Linux Base 6.5-33 [build Jul 30 2008]
> >Copyright (C) 2006 Free Software Foundation, Inc.
> >GDB is free software, covered by the GNU General Public License, and you
> >are
> >welcome to change it and/or distribute copies of it under certain
> >conditions.
> >Type "show copying" to see the conditions.
> >There is absolutely no warranty for GDB. Type "show warranty" for details.
> >This GDB was configured as "--host=i686-pc-linux-gnu --target=sh4-linux".
> >
> The problem is kernel side and not gdb side. I send a patch to the linux-sh
> mailing list. They save the dsp register on the stack before the
> processor cpu register
> but the offset of the struct is wrong calculated and if the linux kernel
> is compiled
> with the dsp option the PEEKUSR return the wrong register value.
>
The sanest thing really is just to throw the DSP state in to the thread
struct as we do with the FPU, and kill off all of the special DSP state
handling we have today. It costs us a thread flag to do lazy context
switching, but it's worth it to get that crap out of the regular register
save/restore paths, which is just way too fragile, and has not seen any
real maintenance since SH3-DSP.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: gdbserver on sh4
2009-03-31 8:23 gdbserver on sh4 Michael Trimarchi
2009-03-31 8:52 ` Paul Mundt
@ 2009-03-31 9:02 ` Michael Trimarchi
2009-03-31 9:03 ` Paul Mundt
2009-03-31 9:08 ` Michael Trimarchi
3 siblings, 0 replies; 5+ messages in thread
From: Michael Trimarchi @ 2009-03-31 9:02 UTC (permalink / raw)
To: linux-sh
Paul Mundt wrote:
> On Tue, Mar 31, 2009 at 10:23:18AM +0200, Michael Trimarchi wrote:
>
>> binom wrote:
>>
>>> Dear michael ,
>>> In your reply message it's written that "I fix this problem".
>>> Can you pl explain what was the problem and and which is the components to
>>> be updated for incorporating this fix?
>>> Below given is the details of the host side GDB and target side gdbserver.
>>> sh4-linux-gdb --version
>>> GNU gdb STMicroelectronics/Linux Base 6.5-33 [build Jul 30 2008]
>>> Copyright (C) 2006 Free Software Foundation, Inc.
>>> GDB is free software, covered by the GNU General Public License, and you
>>> are
>>> welcome to change it and/or distribute copies of it under certain
>>> conditions.
>>> Type "show copying" to see the conditions.
>>> There is absolutely no warranty for GDB. Type "show warranty" for details.
>>> This GDB was configured as "--host=i686-pc-linux-gnu --target=sh4-linux".
>>>
>>>
>> The problem is kernel git clone git://git.openmoko.org/git/kernel.git linux-2.6
>> side and not gdb side. I send a patch to the linux-sh
>> mailing list. They save the dsp register on the stack before the
>> processor cpu register
>> but the offset of the struct is wrong calculated and if the linux kernel
>> is compiled
>> with the dsp option the PEEKUSR return the wrong register value.
>>
>>
> The sanest thing really is just to throw the DSP state in to the thread
> struct as we do with the FPU, and kill off all of the special DSP state
> handling we have today. It costs us a thread flag to do lazy context
>
I just send a patch that put the dsp state in the thread struct
> switching, but it's worth it to get that crap out of the regular register
> save/restore paths, which is just way too fragile, and has not seen any
> real maintenance since SH3-DSP.
>
So move the save/restore part of the dsp in private data of task and do like
mips?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
Michael
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gdbserver on sh4
2009-03-31 8:23 gdbserver on sh4 Michael Trimarchi
2009-03-31 8:52 ` Paul Mundt
2009-03-31 9:02 ` Michael Trimarchi
@ 2009-03-31 9:03 ` Paul Mundt
2009-03-31 9:08 ` Michael Trimarchi
3 siblings, 0 replies; 5+ messages in thread
From: Paul Mundt @ 2009-03-31 9:03 UTC (permalink / raw)
To: linux-sh
On Tue, Mar 31, 2009 at 11:02:38AM +0200, Michael Trimarchi wrote:
> Paul Mundt wrote:
> >On Tue, Mar 31, 2009 at 10:23:18AM +0200, Michael Trimarchi wrote:
> >>The problem is kernel side and not gdb side. I send a patch to the
> >>linux-sh mailing list. They save the dsp register on the stack before
> >>the processor cpu register but the offset of the struct is wrong
> >>calculated and if the linux kernel is compiled with the dsp option
> >>the PEEKUSR return the wrong register value.
> >>
> >The sanest thing really is just to throw the DSP state in to the thread
> >struct as we do with the FPU, and kill off all of the special DSP state
> >handling we have today. It costs us a thread flag to do lazy context
> >
> I just send a patch that put the dsp state in the thread struct
You sent a patch that cached the enable/disable state in the thread
struct, not the register state. ;-)
> >switching, but it's worth it to get that crap out of the regular register
> >save/restore paths, which is just way too fragile, and has not seen any
> >real maintenance since SH3-DSP.
> >
> So move the save/restore part of the dsp in private data of task and do like
> mips?
Yes.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gdbserver on sh4
2009-03-31 8:23 gdbserver on sh4 Michael Trimarchi
` (2 preceding siblings ...)
2009-03-31 9:03 ` Paul Mundt
@ 2009-03-31 9:08 ` Michael Trimarchi
3 siblings, 0 replies; 5+ messages in thread
From: Michael Trimarchi @ 2009-03-31 9:08 UTC (permalink / raw)
To: linux-sh
Hi,
Paul Mundt wrote:
> On Tue, Mar 31, 2009 at 11:02:38AM +0200, Michael Trimarchi wrote:
>
>> Paul Mundt wrote:
>>
>>> On Tue, Mar 31, 2009 at 10:23:18AM +0200, Michael Trimarchi wrote:
>>>
>>>> The problem is kernel side and not gdb side. I send a patch to the
>>>> linux-sh mailing list. They save the dsp register on the stack before
>>>> the processor cpu register but the offset of the struct is wrong
>>>> calculated and if the linux kernel is compiled with the dsp option
>>>> the PEEKUSR return the wrong register value.
>>>>
>>>>
>>> The sanest thing really is just to throw the DSP state in to the thread
>>> struct as we do with the FPU, and kill off all of the special DSP state
>>> handling we have today. It costs us a thread flag to do lazy context
>>>
>>>
>> I just send a patch that put the dsp state in the thread struct
>>
>
> You sent a patch that cached the enable/disable state in the thread
> struct, not the register state. ;-)
>
>
>>> switching, but it's worth it to get that crap out of the regular register
>>> save/restore paths, which is just way too fragile, and has not seen any
>>> real maintenance since SH3-DSP.
>>>
>>>
>> So move the save/restore part of the dsp in private data of task and do like
>> mips?
>>
>
> Yes.
>
Ok, I will try to provide a new patch to move out the dsp save/restore
part from the
stack and move all on the thread privata data.
Michael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread