gdbserver on sh4
|
View:
New views
12 Messages
—
Rating Filter:
Alert me
|
 |
gdbserver on sh4
by Michael Trimarchi-3
::
Rate this Message:
Hi all,
I crosscompile the gdb server for sh and I have trouble to debug a simple application, using it. I try with the gdb-6.8 ./configure --target=sh4-linux gdbserver sh3-linux-gcc is a nptl toolchain CC=sh3-linux-gcc ./configure --host=sh4-linux server side ./gdbserver-6.8 192.168.10.156:1234 ./foobar_sample Process ./foobar_sample created; pid = 817 Listening on port 1234 Remote debugging from host 192.168.8.242 client side GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=sh-linux"... (gdb) target remote 192.168.10.156:1234 Remote debugging using 192.168.10.156:1234 [New Thread 817] Got object file from memory but can't read symbols: File format not recognized. 0x00000000 in ?? () This is how the toolchain is configured sh3-linux-gcc -v Using built-in specs. Target: sh3-linux Configured with: /home/kpit/fsfsrc/v0701/gcc-4.2-20061205/configure --host=i686-linux --target=sh3-linux --prefix=/usr/share/gnush4-nofpu_linux_v0701-1 --with-cpu=sh4-nofpu --with-sysroot=/usr/share/gnush4-nofpu_linux_v0701-1/sh3-linux/sys-root --with-local-prefix=/usr/share/gnush4-nofpu_linux_v0701-1/sh3-linux/sys-root --disable-nls --enable-threads --enable-symvers=gnu --disable-__cxa_atexit --enable-languages=c,c++ --enable-c99 --enable-long-long --disable-multilib (gdb) b main Breakpoint 1 at 0x4003e6: file main.c, line 23. (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x7b9dedec in ?? () (gdb) Can anybody help to find the problem? Kind regards Michael |
|
|
Re: gdbserver on sh4
by Michael Trimarchi-3
::
Rate this Message:
Hi,
michael wrote: > Hi all, > > I crosscompile the gdb server for sh and I have trouble to debug a > simple application, > using it. > > I try with the gdb-6.8 > > ./configure --target=sh4-linux > > gdbserver > sh3-linux-gcc is a nptl toolchain > > CC=sh3-linux-gcc ./configure --host=sh4-linux > > server side > > ./gdbserver-6.8 192.168.10.156:1234 > ./foobar_sample Process ./foobar_sample created; > pid = 817 Listening on port > 1234 Remote > debugging from host 192.168.8.242 > > client side > GNU gdb 6.8 > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "--host=x86_64-unknown-linux-gnu > --target=sh-linux"... > (gdb) target remote 192.168.10.156:1234 > Remote debugging using 192.168.10.156:1234 > [New Thread 817] > Got object file from memory but can't read symbols: File format not > recognized. > 0x00000000 in ?? () > > This is how the toolchain is configured > sh3-linux-gcc -v > Using built-in specs. > Target: sh3-linux > Configured with: /home/kpit/fsfsrc/v0701/gcc-4.2-20061205/configure > --host=i686-linux --target=sh3-linux > --prefix=/usr/share/gnush4-nofpu_linux_v0701-1 --with-cpu=sh4-nofpu > --with-sysroot=/usr/share/gnush4-nofpu_linux_v0701-1/sh3-linux/sys-root > --with-local-prefix=/usr/share/gnush4-nofpu_linux_v0701-1/sh3-linux/sys-root > --disable-nls --enable-threads --enable-symvers=gnu > --disable-__cxa_atexit --enable-languages=c,c++ --enable-c99 > --enable-long-long --disable-multilib > > (gdb) b main > Breakpoint 1 at 0x4003e6: file main.c, line 23. > (gdb) c > Continuing. > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x7b9dedec in ?? () > (gdb) > > Can anybody help to find the problem? > > Kind regards > Michael > > > > > > Michael |
|
|
Re: gdbserver on sh4
by binom
::
Rate this Message:
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". gdbserver --version GNU gdbserver STMicroelectronics/Linux Base 6.5-15 Copyright (C) 2006 Free Software Foundation, Inc. gdbserver is free software, covered by the GNU General Public License. This gdbserver was configured as "sh4-linux" Thankx, Bino
|
|
|
Re: gdbserver on sh4
by Michael Trimarchi-2
::
Rate this Message:
Hi,
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". > 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. Michael |
|
|
Re: gdbserver on sh4
by Paul Mundt
::
Rate this Message:
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. > 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. |
|
|
Re: gdbserver on sh4
by Michael Trimarchi-2
::
Rate this Message:
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 > > 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@... > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Michael |
|
|
Re: gdbserver on sh4
by Paul Mundt
::
Rate this Message:
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. |
|
|
Re: gdbserver on sh4
by Michael Trimarchi-2
::
Rate this Message:
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. > 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@... > More majordomo info at http://vger.kernel.org/majordomo-info.html > > |
|
|
Re: gdbserver on sh4
by damien.courousse.logica
::
Rate this Message:
Hello all,
|
|
|
Re: gdbserver on sh4
by Michael Trimarchi-3
::
Rate this Message:
damien.courousse.logica wrote:
> Hello all, > > > 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. > > > > I am currently facing the same problem that is described in this thread, > also on sh4. > Michael did you provide a kernel patch to fix this? If possible, how could I > help you? > kernel version do you use? Michael |
|
|
Re: gdbserver on sh4
by damien.courousse.logica
::
Rate this Message:
Hi Michael, I use a kernel source tree modified by STmicroelectronics : linux-sh4-STAPI_2.6.23.17_stm23_A16 - it is based on the kernel 2.6.23. Damien |
|
|
|
| Free embeddable forum powered by Nabble | Forum Help |
