This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb failed to set a breakpoint on Windows


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]