From: asmwarrior <asmwarrior@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: gdb failed to set a breakpoint on Windows
Date: Sat, 04 Jun 2011 11:59:00 -0000 [thread overview]
Message-ID: <4DEA1E96.8060403@gmail.com> (raw)
In-Reply-To: <4DE9C7A7.9050009@gmail.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
next prev parent reply other threads:[~2011-06-04 11:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-04 5:48 asmwarrior
2011-06-04 11:59 ` asmwarrior [this message]
2011-06-04 16:46 ` Keith Seitz
2011-06-05 1:59 ` asmwarrior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DEA1E96.8060403@gmail.com \
--to=asmwarrior@gmail.com \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).