This is the mail archive of the 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: setting a breakpoint on a dll, relative path or absolute path issue

On 2011-6-12 11:58, asmwarrior wrote:
On 2011-6-12 1:08, Keith Seitz wrote:
On 06/11/2011 12:52 AM, asmwarrior wrote:
Can you give me a direction that I can dig into the gdb's source?

This is almost certainly PR 12843:

This was caused, I believe, by this patch hunk (for locate_first_half in
linespec.c), which I committed for c++/12750 on 2011-05-31:

@@ -1160,13 +1207,11 @@ locate_first_half (char **argptr, int
/* Check for the end of the first half of the linespec. End of
- line, a tab, a double colon or the last single colon, or a
- space. But if enclosed in double quotes we do not break on
- enclosed spaces. */
+ line, a tab, a colon or a space. But if enclosed in double
+ quotes we do not break on enclosed spaces. */
if (!*p
|| p[0] == '\t'
- || ((p[0] == ':')
- && ((p[1] == ':') || (strchr (p + 1, ':') == NULL)))
+ || (p[0] == ':')
|| ((p[0] == ' ') && !*is_quote_enclosed))
if (p[0] == '.' && strchr (p, ':') == NULL)

I am intending to get to this, but it will probably not be until later
this coming week.


Hi, Keith, thanks for the reply. I have reverted the patch hunk in the
locate_first_half function and build gdb again, now, I can set
breakpoint like:

 > break
Breakpoint 1 at 0x401d09: file
E:\code\cb\test_code\debug_wx_library\debug_wx_libraryMain.cpp, line 101.

So, the PR 12843 can be solved.
But what I have mentioned in my OP is another issue about setting
breakpoint, that is:

gdb failed on setting a breakpoint on a shared dll(the dll is build with
the relative paths)

break "E:/code/cb/wx/wxWidgets-2.8.12/src/common/string.cpp:164"
No source file named E:/code/cb/wx/wxWidgets-2.8.12/src/common/string.cpp.
Breakpoint 2 ("E:/code/cb/wx/wxWidgets-2.8.12/src/common/string.cpp:164)
But the breakpoint can be set by using two ways below:
 > break ../../src/common/string.cpp:164
Breakpoint 3 at 0x66d89f44: file ../../src/common/string.cpp, line 164.
 > break
Breakpoint 4 at 0x66d89f44: file ../../src/common/string.cpp, line 164.
What I expect is the let the first way work.

So, I would like to find some gdb source snippet which handle the file
path match algorithm, so that all the three methods can work. Can you
give me a direction?

ollydbg from code::blocks' forum

Hi, all, by reading the gdb's source, I found that why setting breakpoint faild on this situation, here is my observation:

When I run the gdb command: info sources

Then, I found that there's on source line named:


This line can be list in symbols or psymbols.

Now, a user try to set a breakpoint, he can use a FILE:LINE format, gdb try to match the FILE in all the sources.

The match algorithm was mainly in: gdbgit\gdb\gdb\symtab.c
in function: struct symtab * lookup_symtab (const char *name)

There are three match algorithms involved:
1, exact match
If the user supply the string:
Then, it will have a exact match, and the breakpoint can set correctly.

2, tailed match
If the user supply the string:
It will still match that string in the symbol table, so it works OK.

3, transferred match, this is why things break down

If the user supply a string:
Now, gdb try to below:

const char *fp = symtab_to_fullname (s);

if (fp != NULL && FILENAME_CMP (full_path, fp) == 0)
do_cleanups (cleanup);
return s;
Note, the s is every string shown in the "info sources", and full_path is the user supplied string, so if the function symtab_to_fullname (s) correctly transferred to
Then, this will get matched.

So, as a conclusion:
1, either we should store the
instead of
in the symbol tables.

2, or we need to fix the way I said before "transferred match", so they can still get matched.

Any ideas?

ollydbg from codeblocks' forum

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