thread debugging with gdb

Hans-Christian Egtvedt hcegtvedt at atmel.com
Mon Feb 11 07:55:03 UTC 2008


On Mon, 2008-02-11 at 08:44 +0100, juanba romance wrote:
> On Feb 11, 2008 7:45 AM, Hans-Christian Egtvedt <hcegtvedt at atmel.com>
> wrote:

PS! Do not drop the mailinglist address. Other may be interested or want
to contribute to the discussion.

>         On Sun, 2008-02-10 at 18:11 +0100, juanba romance wrote:
>         > Same behaviour for the AVR32 AP7 processor using the next
>         tags
>         > avr32-linux-gcc 4.2.1-atmel.1.0.3
>         > gdb-6.4.atmel.1.0.1
>         > linux-kernel-2.6.18
>         
>         
>         Please upgrade to v2.6.24.atmel.1 to get the debugging fixes.
>  
> Ok, i changed above software chain provided  by the official BSP to
> the buildroot environment
> which  refresh all this stuff to the 2.6.23 kernel tag, maybe enough
>  

Nope, the kernel in Buildroot for AVR32 fork does not have the debug
fix. The easiest is to grab the kernel from
http://avr32linux.org/twiki/bin/view/Main/LinuxPatches and compile it
with the toolchain you generate with Buildroot. Then replace
the /lib/modules and /boot/uImage in your image.

>         > uclibc-0.9.28
>         >
>         Again, I think Subversion HEAD will be better than 0.9.28.
>         
> The buildroot provides the  0.9.29 tag as above i assume also that's
> enough
> 

Yes, the Buildroot uClibc should be fine.

>         > Which is the current status for this issue ?
>         What issue? Debugging threads?
> Yes..
>  
> 
>         Did you build uClibc with debuggable
>         
>         threads?
> Not yet i unpackaged the NGW100 kit on saturday and i was only
> checking the default provided environment, Anyway the the buildroot
> has already manufactured the images and all the stuff, but yes this
> time i have toggled CONFIG_BR2_PTHREAD_DEBUG option i mean it's
> related on isn't it? 
> 

If the file in toolchain_build_avr32_nofpu/uClibc-0.9.29/.config has
PTHREADS_DEBUG_SUPPORT=y, then you should be fine.

-- 
With kind regards,
Hans-Christian Egtvedt, Applications Engineer




More information about the uClibc mailing list