Re: gdb failed to set a breakpoint on Windows

[asmwarrior <asmwarrior at gmail dot com>]

On 2011-6-4 13:50, asmwarrior wrote:
> Hi, today, I build a gdb-7.3.50.20110604 cvs gdb version under MinGW and
> MSYS.
>
> But when debugging, gdb failed to set a breakpoint, it seems it failed
> to handle the windows style file path.
>
> look at the log:
>
>  > break
> "E:/code/cb/cb_trunk/src/plugins/codecompletion/parser/parserthread.cpp:524"
>
> No source file named E.
> Breakpoint 2
> ("E:/code/cb/cb_trunk/src/plugins/codecompletion/parser/parserthread.cpp:524)
> pending.
>  >>>>>>cb_gdb:
>
> You see, "No source file named E.", this is the error message.
>
> the gdb 20110401 cvs snapshot build works quite well on setting
> breakpoints.
>
> any ideas?
>
> thank you!
>
> asmwarrior
> ollydbg from codeblocks' forum
Ok, I found that the change in linespec.c in
http://sourceware.org/ml/gdb-cvs/2011-05/msg00255.html
and
http://sourceware.org/ml/gdb-cvs/2011-05/msg00196.html

cause this issue.

If I replace the lincespec.c with an old version of linespec.c before 
May 24, 2011, then gdb build 20110604snapshot can correctly set 
breakpoints under Windows.

So, hope some gdb developers can fix this issue. Mostly, I guess is 
kseitz. ^_^.


By the way, when debugging code::blocks, I will have a long function 
argument value, see the log when showing a call stack:

> bt 30
#0  ParserThread::DoParse (this=0x230bc70) at 
E:\code\cb\cb_trunk\src\plugins\codecompletion\parser\parserthread.cpp:525
#1  0x65ec6743 in ParserThread::Parse (this=0x230bc70) at 
E:\code\cb\cb_trunk\src\plugins\codecompletion\parser\parserthread.cpp:482
#2  0x65ec289f in Parser::Parse (this=0x3e74c38, 
bufferOrFilename="#define __DBL_MIN_EXP__ (-1021)\n#define 
__pentiumpro__ 1\n#define __UINT_LEAST16_MAX__ 65535\n#define 
__FLT_MIN__ 1.17549435082228750797e-38F\n#define __UINT_LEAST8_TYPE__ 
unsigned char\n#define _WIN32 1\n#define __INTMAX_C(c) c ## LL\n#define 
__CHAR_BIT__ 8\n#define __UINT8_MAX__ 255\n#define __WINT_MAX__ 
65535\n#define __SIZE_MAX__ 4294967295U\n#define __WCHAR_MAX__ 
65535\n#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1\n#define
......
too many lines
......

__FLT_MIN_10_EXP__ (-37)\n#define __INTMAX_TYPE__ long long int\n#define 
i386 1\n#define _INTEGRAL_MAX_BITS 64\n#define __DEC128_MAX_EXP__ 
6145\n#define __GNUC_MINOR__ 5\n#define __UINTMAX_MAX__ 
18446744073709551615ULL\n#define __DEC32_MANT_DIG__ 7\n#define 
__DBL_MAX_10_EXP__ 308\n#define __LDBL_DENORM_MIN__ 
3.64519953188247460253e-4951L\n#define __INT16_C(c) c\n#define __STDC__ 
1\n#define __PTRDIFF_TYPE__ int\n#define __UINT32_TYPE__ unsigned 
int\n#define __UINTPTR_TYPE__ unsigned int\n#define 
__DEC64_SUBNORMAL_MIN__ 0.", '0' <repeats 14 times>, "1E-383DD\n#define 
__DEC128_MANT_DIG__ 34\n#define __LDBL_MIN_10_EXP__ (-4931)\n#define 
__SIZEOF_LONG_LONG__ 8\n#define __LDBL_DIG__ 18\n#define 
__UINT_FAST16_MAX__ 65535\n#define __GNUC_GNU_INLINE__ 1\n#define 
__UINT_FAST8_TYPE__ unsigned char\n#define __declspec(x) 
__attribute__((x))\n#define __cplusplus\n", isLocal=false, opts=...) at 
E:\code\cb\cb_trunk\src\plugins\codecompletion\parser\parser.cpp:531
#3  0x65eefd0c in AddParseThread::Execute (this=0x3ef7e90) at 
E:\code\cb\cb_trunk\src\plugins\codecompletion\parser\parser.cpp:104
#4  0x617e79f2 in cbThreadPool::cbWorkerThread::Entry (this=0x3e614f0) 
at E:\code\cb\cb_trunk\src\sdk\cbthreadpool.cpp:228
#5  0x00bbc409 in wxThreadInternal::DoThreadStart(wxThread*) () from 
E:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
#6  0x00bbc4fb in wxThreadInternal::WinThreadStart () from 
E:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
#7  0x77c3a3b0 in msvcrt!_endthreadex () from C:\WINDOWS\system32\msvcrt.dll
#8  0x7c80b729 in KERNEL32!GetModuleFileNameA () from 
C:\WINDOWS\system32\kernel32.dll
#9  0x00000000 in ?? ()



it seems the function argument bufferOrFilename is a wxString, which has 
a large lengths. it shows the full contents of the string by wxWidgets 
python pretty printer, can we limit the lengths showing on the 
call-stack? (this issue also exists when showing a long std::string or 
alike)

any ideas?

thanks.

asmwarrior
ollydbg from codeblocks' forum