[Cegcc-devel] gdb & watch points
Hi,
also discovered watchpoints don't work. Not sure the kinda effort it'd
take to support them for that platform. Probably gdbserver doesn't
know how to handle those. The output is:
[EMAIL PROTECTED] ws]# /opt/mingw32ce/bin/arm-mingw32ce-gdb wct
GNU gdb 6.8
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-mingw32ce"...
(gdb) target remote 169.254.2.1:
Reading symbols from /root/ws/cegcc.dll...done.
Loaded symbols for cegcc.dll
_mainCRTStartup ()
at /root/ws/cegcc/cegcc/src/newlib/newlib/libc/sys/wince/crt0.S:25
25 stmdb sp!, {r11, lr}
Current language: auto; currently asm
(gdb) watch __wcetrace
Hardware watchpoint 1: __wcetrace
(gdb) print __wcetrace
$1 = 0x0
(gdb) continue
Continuing.
Warning:
Could not insert hardware watchpoint 1.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
This gave the same result:
(gdb) print &__wcetrace
$1 = (int *) 0xbe2a90
(gdb) watch *0xbe2a90
Hardware watchpoint 1: *0xbe2a90
(gdb) continue
Continuing.
Warning:
Could not insert hardware watchpoint 1.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
--
With best of best regards
Pawel S. Veselov
{resend, bounced from source forge}
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] gdb & watch points
On Tuesday 23 September 2008 17:29:08, Pawel Veselov wrote: > Hi, > > also discovered watchpoints don't work. Not sure the kinda effort it'd > take to support them for that platform. Probably gdbserver doesn't > know how to handle those. The output is: gdbserver's common code has support for these, but, only the crisv32-linux supports them as of this date... not even the x86-linux port has support for those. Try setting 'set can-use-hw-watchpoints 0' to force software watchpoints. Not every arm supports watchpoints, and, I don't remember seeing any watchpoint related debug register exported on winnt.h:struct _CONTEXT ... That is, not sure if MSFT's debug API exports any way to set/read those. I'd glad to be proven wrong though. It would be great to be able to set hardware breakpoints in ROM dlls... Can MSFT's debugger do hardware watchpoints? -- Pedro Alves - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] Fail to compile gdb
On Wednesday 17 September 2008 20:54:27, Pedro Alves wrote: > On Wednesday 17 September 2008 20:14:52, Pawel Veselov wrote: > > I get this every now and then on some "stuck" applications: > > > > Program received signal SIGTRAP, Trace/breakpoint trap. > > 0x8001b6ec in ?? () > > (gdb) where > > #0 0x8001b6ec in ?? () > > (gdb) info threads > > * 1 Thread 1154900630 0x8001b6ec in ?? () > > warning: Couldn't restore frame in current thread, at frame 0 > > 0x8001b6ec in ?? () > > Ok, is it always the same address? It's been a while, but I > think you get that when the thread is stuck inside a > system call. If so, I don't expect this to be worse than what it > was with the older gdb in our tree, and we do need to teach GDB > how to unwind passed that. BTW, I just confirmed that I get the same behaviour on Visual Studio 2008. This usually means the app is stopped inside a system call (e.g., calling into coredll.dll using the cross-process CE system call magic), e.g., Sleep. Not sure if its possible to unwind from there without debug info, and the fact that MSFT's debugger can't do it OOTB, kind'a unmotivates :-/ (haven't confirmed if I have all the debug info necessary, but that would just prove that debug info is needed. Anyone willing to teach GDB about PDBs?) -- Pedro Alves - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
[Cegcc-devel] build-cegcc.sh replumbing
Hi folks, I've reorganized a bit build-mingw32ce.sh, and in the process, done something that I'd been meaning to do for a long time. I've converted the build-cegcc.sh build script to be similar to build-mingw32ce.sh. Besides consistency, I wanted to do this so cegcc also uses w32api --- it was still using old pre-w32api cegcc/importlibs dir, which can now go away. This means people have access to as many win32 apis from cegcc as from mingw32ce, which was not true before. Let me know if this caused any trouble. (building cegcc is in need of love. I'd love it if we got rid of the hacks under src/cegcc/ ...) -- Pedro Alves - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
