setting a breakpoint on a dll, relative path or absolute path issue

setting a breakpoint on a dll, relative path or absolute path issue

[asmwarrior]

I meet some problems on setting a break point on a shared dll. (I'm 
using gdb cvs 20110401 mingw32 build version)
The dll is build with relative sources paths, and my main App was build 
with absolute source paths.

the dll is a debug version of wxWidgets shared library, locates in:
E:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28ud_gcc_custom.dll

Here is the debug log:

--------------------------------------------------------
info sources
Source files for which symbols have been read in:
E:\code\cb\test_code\debug_wx_library\debug_wx_libraryMain.cpp, 
E:/code/cb/wx/wxWidgets-2.8.12/include/wx/generic/textdlgg.h,
...
e:/code/cb/gcc/mingw_gcc4.5.4.20110428_static_win32/mingw/bin/../lib/gcc/i686-pc-mingw32/4.5.4/include/c++/i686-pc-mingw32/bits/gthr-default.h, 

E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../include/wx/filefn.h, 
E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../include/wx/filename.h,
...
Source files for which symbols will be read in on demand:

../.././libgcc/../gcc/gthr-win32.h,

...

E:/code/cb/wx/wxWidgets-2.8.12/include/wx/list.h, 
E:/code/cb/wx/wxWidgets-2.8.12/include/wx/object.h,
...
../../include/wx/vector.h, ../../include/wx/clntdata.h,

...

../../src/richtext/richtextstylepage.cpp,
...

--------------------------------------------------------
Now, I try to set break points on the shared dll's source file:


--------------------------------------------------------
 >>>>>>cb_gdb:
 > b "../../include/wx/spinbutt.h:20"
Breakpoint 2 at 0x67109942: file ../../include/wx/spinbutt.h, line 40. 
(3 locations)
 >>>>>>cb_gdb:
 > b 
"E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp:161"
Breakpoint 3 at 0x66d89efd: file ../../src/common/string.cpp, line 161.
 >>>>>>cb_gdb:
 > b "../../src/common/string.cpp:161"
Breakpoint 4 at 0x66d89efd: file ../../src/common/string.cpp, line 161.
 >>>>>>cb_gdb:
 > b "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 5 ("E:\code\cb\wx\wxWidgets-2.8.12\src/common/string.cpp:164) 
pending.
 >>>>>>cb_gdb:
 > b "../../src/common/datetime.cpp:100"
Breakpoint 6 at 0x66d47ba5: file ../../src/common/datetime.cpp, line 100.
 >>>>>>cb_gdb:
 > b 
"E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/datetime.cpp:101"
--------------------------------------------------------


The strange thing is:
when I pass a true path 
"E:\code\cb\wx\wxWidgets-2.8.12\src/common/string.cpp", then the 
breakpoint failed, gdb report that there is no such source file.

But when using "../../src/common/datetime.cpp" or 
"E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp", 
the breakpoint can be set correctly.

So, can some gdb developers can tell the truth why this would happen?
I think at least when using 
"E:\code\cb\wx\wxWidgets-2.8.12\src/common/string.cpp", the breakpoint 
should set correctly.

Can you give me a direction that I can dig into the gdb's source?

thanks.

PS:
The related discussion can be found here:
http://forums.codeblocks.org/index.php/topic,14792.msg99482/topicseen.html#msg99482
and
http://forums.codeblocks.org/index.php/topic,13306.msg89692.html#msg89692

thanks you very much!

asmwarrior
ollydbg from codeblocks' forum

Re: setting a breakpoint on a dll, relative path or absolute path issue

[Keith Seitz]

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:

http://sourceware.org/bugzilla/show_bug.cgi?id=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 
*is_quote_enclosed
           break;
         }
        /* 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))
         break;
        if (p[0] == '.' && strchr (p, ':') == NULL)

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

Keith

Re: setting a breakpoint on a dll, relative path or absolute path issue

[asmwarrior]

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:
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=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
> *is_quote_enclosed
> break;
> }
> /* 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))
> break;
> if (p[0] == '.' && strchr (p, ':') == NULL)
>
> I am intending to get to this, but it will probably not be until later
> this coming week.
>
> Keith
>
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 
"E:/code/cb/test_code/debug_wx_library/debug_wx_libraryMain.cpp:101"
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) 
pending.
------------------------------------------------------------------
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.
 >>>>>>cb_gdb:
 > break 
E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp:164
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?

thanks.
asmwarrior
ollydbg from code::blocks' forum

Re: setting a breakpoint on a dll, relative path or absolute path issue

[asmwarrior]

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:
>>
>> http://sourceware.org/bugzilla/show_bug.cgi?id=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
>> *is_quote_enclosed
>> break;
>> }
>> /* 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))
>> break;
>> if (p[0] == '.' && strchr (p, ':') == NULL)
>>
>> I am intending to get to this, but it will probably not be until later
>> this coming week.
>>
>> Keith
>>
> 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
> "E:/code/cb/test_code/debug_wx_library/debug_wx_libraryMain.cpp:101"
> 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)
> pending.
> ------------------------------------------------------------------
> 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.
>  >>>>>>cb_gdb:
>  > break
> E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp:164
> 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?
>
> thanks.
> asmwarrior
> 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:

E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/datetime.cpp

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:
"E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/datetime.cpp"
Then, it will have a exact match, and the breakpoint can set correctly.

2, tailed match
If the user supply the string:
"../../src/common/datetime.cpp"
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:
"E:/code/cb/wx/wxWidgets-2.8.12/src/common/datetime.cpp"
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
"E:/code/cb/wx/wxWidgets-2.8.12/src/common/datetime.cpp"
Then, this will get matched.

So, as a conclusion:
1, either we should store the
"E:/code/cb/wx/wxWidgets-2.8.12/src/common/datetime.cpp"
instead of
"E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/datetime.cpp"
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?

asmwarrior
ollydbg from codeblocks' forum

Re: setting a breakpoint on a dll, relative path or absolute path issue

[Jan Kratochvil]

On Sun, 12 Jun 2011 09:47:37 +0200, asmwarrior wrote:
> 1, either we should store the
> "E:/code/cb/wx/wxWidgets-2.8.12/src/common/datetime.cpp"
> instead of
> "E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/datetime.cpp"
> in the symbol tables.

This does not work, the paths are not the same:
$ mkdir dir dir/subdir; echo file >dir/file; ln -s dir/subdir symlink; cat symlink/../file file
file
cat: file: No such file or directory

And one of the MinGW principles is to keep the backslashed names (\), not to
translate them to slashed ones (/) like CygWin does.


Regards,
Jan

Re: setting a breakpoint on a dll, relative path or absolute path issue

[asmwarrior]

On 2011-6-12 15:56, Jan Kratochvil wrote:
> On Sun, 12 Jun 2011 09:47:37 +0200, asmwarrior wrote:
>> 1, either we should store the
>> "E:/code/cb/wx/wxWidgets-2.8.12/src/common/datetime.cpp"
>> instead of
>> "E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/datetime.cpp"
>> in the symbol tables.
>
> This does not work, the paths are not the same:
> $ mkdir dir dir/subdir; echo file>dir/file; ln -s dir/subdir symlink; cat symlink/../file file
> file
> cat: file: No such file or directory
>
> And one of the MinGW principles is to keep the backslashed names (\), not to
> translate them to slashed ones (/) like CygWin does.
>
>
> Regards,
> Jan
>
Hi, thanks for the reply.
In-fact, personally, I'm not care about whether we use forward slash or 
backward slash. If it break something, we can consider another way.

So, as you said, the proposed method 1 is not suitable, can we use or 
improve the method 2?

asmwarrior
ollydbg from Code::blocks' forum

Re: [Mingw-users] setting a breakpoint on a dll, relative path or absolute path issue

[Earnie]

asmwarrior wrote:
> On 2011-6-12 15:56, Jan Kratochvil wrote:
>> On Sun, 12 Jun 2011 09:47:37 +0200, asmwarrior wrote:
>>> 1, either we should store the
>>> "E:/code/cb/wx/wxWidgets-2.8.12/src/common/datetime.cpp"
>>> instead of
>>> "E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/datetime.cpp"
>>> in the symbol tables.
>>
>> This does not work, the paths are not the same:
>> $ mkdir dir dir/subdir; echo file>dir/file; ln -s dir/subdir symlink; cat symlink/../file file
>> file
>> cat: file: No such file or directory
>>
>> And one of the MinGW principles is to keep the backslashed names (\), not to
>> translate them to slashed ones (/) like CygWin does.
>>
>>

This isn't exactly true.  We use / instead of \ except for when using
CreateProcess since the API will understand them and it is more work to
use \ instead of /.  The process actually uses both \ and / as equals.

-- 
Earnie
-- http://www.for-my-kids.com

Re: setting a breakpoint on a dll, relative path or absolute path issue

[Eli Zaretskii]

> Date: Sun, 12 Jun 2011 09:56:31 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: Keith Seitz <keiths@redhat.com>, gdb@sourceware.org,        MinGW Users List <mingw-users@lists.sourceforge.net>
> 
> On Sun, 12 Jun 2011 09:47:37 +0200, asmwarrior wrote:
> > 1, either we should store the
> > "E:/code/cb/wx/wxWidgets-2.8.12/src/common/datetime.cpp"
> > instead of
> > "E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/datetime.cpp"
> > in the symbol tables.
> 
> This does not work, the paths are not the same:

Why do you say that?

> $ mkdir dir dir/subdir; echo file >dir/file; ln -s dir/subdir symlink; cat symlink/../file file
> file
> cat: file: No such file or directory

MinGW doesn't support symlinks, so how is this relevant?  What am I
missing?

> And one of the MinGW principles is to keep the backslashed names (\), not to
> translate them to slashed ones (/) like CygWin does.

Right.  Which is why TRT is to modify FILENAME_CMP to compare slashes
and backslashes equal.

Re: setting a breakpoint on a dll, relative path or absolute path issue

[Jan Kratochvil]

On Sun, 12 Jun 2011 18:49:33 +0200, Eli Zaretskii wrote:
> > This does not work, the paths are not the same:
> 
> Why do you say that?

It looked to me as a general suggestion to GDB behavior change.


> > $ mkdir dir dir/subdir; echo file >dir/file; ln -s dir/subdir symlink; cat symlink/../file file
> > file
> > cat: file: No such file or directory
> 
> MinGW doesn't support symlinks, so how is this relevant?  What am I
> missing?

It could be made only a MinGW specific code but I made a note it is not
applicable in general (in fact someone made such note to me before).


Regards,
Jan

Re: setting a breakpoint on a dll, relative path or absolute path issue

[asmwarrior]

On 2011-6-11 22:25, Earnie wrote:
> asmwarrior wrote:
>> The strange thing is:
>> when I pass a true path
>> "E:\code\cb\wx\wxWidgets-2.8.12\src/common/string.cpp", then the
>> breakpoint failed, gdb report that there is no such source file.
>>
>> But when using "../../src/common/datetime.cpp" or
>> "E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp",
>> the breakpoint can be set correctly.
>>
>> So, can some gdb developers can tell the truth why this would happen?
>> I think at least when using
>> "E:\code\cb\wx\wxWidgets-2.8.12\src/common/string.cpp", the breakpoint
>> should set correctly.
>>
>
> I'm not a gdb developer nor do I use it often but I'm of the opinion
> that gdb isn't looking on disk for the file and is looking instead for a
> match in a record in the object data.  Does it help if you use the
> --directory=/path/to/source/files switch?

My dll was located in:
E:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28ud_gcc_custom.dll
and when build this dll, I use the make file locates in:
E:\code\cb\wx\wxWidgets-2.8.12\build\msw\makefile.gcc
and all the sources were under:
E:\code\cb\wx\wxWidgets-2.8.12\src

I have manually add the directory by using those command:
dir E:/code/cb/wx/wxWidgets-2.8.12/build/msw
dir E:/code/cb/wx/wxWidgets-2.8.12/src
dir dir E:/code/cb/wx/wxWidgets-2.8.12/lib/gcc_dll

and now, I try to set a break point:
 > 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 3 ("E:/code/cb/wx/wxWidgets-2.8.12/src/common/string.cpp:164) 
pending.

Which means: passing the absolute path still failed.

------------------------------------------------------------

The strange thing is that passing a relative path works
 > break "../../src/common/string.cpp:164"
Breakpoint 4 at 0x66d89f44: file ../../src/common/string.cpp, line 164.

This means that gdb internally know this relative path matches some 
debugging symbols.

The more strange thing is, if the path was supplied by this:
 >>>>>>cb_gdb:
 > break 
E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp:164
Breakpoint 2 at 0x66d89f44: file ../../src/common/string.cpp, line 164.

 >>>>>>cb_gdb:
 > break 
E:\code\cb\wx\wxWidgets-2.8.12\src\common/../../src/common/string.cpp:165
No source file named 
E:\code\cb\wx\wxWidgets-2.8.12\src\common/../../src/common/string.cpp.
Breakpoint 3 
(E:\code\cb\wx\wxWidgets-2.8.12\src\common/../../src/common/string.cpp:165) 
pending.

 >>>>>>cb_gdb:
 > break 
E:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll/../../src/common/string.cpp:165
No source file named 
E:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll/../../src/common/string.cpp.
Breakpoint 4 
(E:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll/../../src/common/string.cpp:165) 
pending.
 >>>>>>cb_gdb:

You can see: if the relative path is followed by
E:\code\cb\wx\wxWidgets-2.8.12\build\msw
the breakpoint can be set correctly.

If the relative path is followed by some other path like:
E:\code\cb\wx\wxWidgets-2.8.12\src\common
or
E:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll
The breakpoint can't be set.

>
>> Can you give me a direction that I can dig into the gdb's source?
>
> Sorry, no, debugging the debugger is an awesome task and one I've never
> desired to do. Good luck on your journey into this venture, I truly wish
> you well.  There has been little development in gdb on Windows that I
> know of and it would be good if someone had the heart to put some love
> into it.
>
thanks for the encourage, and I will do my best to contribute.

asmwarrior
ollydbg from codeblocks' forum

Re: setting a breakpoint on a dll, relative path or absolute path issue

[Asm warrior]

I just go a little further, and found that there is a function to look 
up a file name in symbol tables.

struct symtab * lookup_symtab (const char *name)

the parameter name is the user supplied file name string to set a 
breakpoint.

This function will loop all the symbols and do a string match.

symtab_to_fullname() is used to read symbol's filename, it was defined 
in the gdb/source.c line 1110


char *
symtab_to_fullname (struct symtab *s)
{
   int r;

   if (!s)
     return NULL;

   /* Don't check s->fullname here, the file could have been
      deleted/moved/..., look for it again.  */
   r = find_and_open_source (s->filename, s->dirname, &s->fullname);

   if (r >= 0)
     {
       close (r);
       return s->fullname;
     }

   return NULL;
}

When loop on the symbols. I found that at one loop, I get

s->filename = "../../src/common/string.cpp"
s->dirname  = "D:\code\wxWidgets-2.8.12\build\msw"

But too badly, the result
s->fullname = 
"D:\code\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp"

This is the reason about the issue, if the result is:
"D:\code\wxWidgets-2.8.12/src/common/string.cpp"
Then, this problem can be fixed.

I'm not sure why gdb does not give a cannical filename, but still leaves 
the "../../" in the result.



By the way, gdb's matching algorithm care both "/" and "\" as equivalent 
char under Windows.

Look at here: gdb\libiberty\filename_cmp.c

int
filename_cmp (const char *s1, const char *s2)
{
#ifndef HAVE_DOS_BASED_FILE_SYSTEM
  return strcmp(s1, s2);
#else
  for (;;)
     {
      int c1 = TOLOWER (*s1);
      int c2 = TOLOWER (*s2);

      /* On DOS-based file systems, the '/' and the '\' are equivalent.  */
      if (c1 == '/')
        c1 = '\\';
      if (c2 == '/')
        c2 = '\\';

      if (c1 != c2)
        return (c1 - c2);

      if (c1 == '\0')
        return 0;

      s1++;
      s2++;
     }
#endif
}


Asmwarrior
ollydbg from codeblocks' forum

Re: setting a breakpoint on a dll, relative path or absolute path issue

[Eli Zaretskii]

> Date: Mon, 13 Jun 2011 14:29:28 +0800
> From: Asm warrior <asmwarrior@gmail.com>
> CC: "John E. / TDM" <tdragon@tdragon.net>, Eli Zaretskii <eliz@gnu.org>, 
>  jan.kratochvil@redhat.com, keiths@redhat.com
> 
> When loop on the symbols. I found that at one loop, I get
> 
> s->filename = "../../src/common/string.cpp"
> s->dirname  = "D:\code\wxWidgets-2.8.12\build\msw"
> 
> But too badly, the result
> s->fullname = 
> "D:\code\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp"
> 
> This is the reason about the issue, if the result is:
> "D:\code\wxWidgets-2.8.12/src/common/string.cpp"
> Then, this problem can be fixed.
> 
> I'm not sure why gdb does not give a cannical filename, but still leaves 
> the "../../" in the result.

Because the function that canonicalizes the file name does not support
backslashes correctly?

> By the way, gdb's matching algorithm care both "/" and "\" as equivalent 
> char under Windows.

Right, that was changed lately.

Re: setting a breakpoint on a dll, relative path or absolute path issue

[Asm warrior]

On 2011-6-14 0:59, Eli Zaretskii wrote:
>> Date: Mon, 13 Jun 2011 14:29:28 +0800
>> >  From: Asm warrior<asmwarrior@gmail.com>
>> >  CC: "John E. / TDM"<tdragon@tdragon.net>, Eli Zaretskii<eliz@gnu.org>,
>> >    jan.kratochvil@redhat.com,keiths@redhat.com
>> >
>> >  When loop on the symbols. I found that at one loop, I get
>> >
>> >  s->filename = "../../src/common/string.cpp"
>> >  s->dirname  = "D:\code\wxWidgets-2.8.12\build\msw"
>> >
>> >  But too badly, the result
>> >  s->fullname =
>> >  "D:\code\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp"
>> >
>> >  This is the reason about the issue, if the result is:
>> >  "D:\code\wxWidgets-2.8.12/src/common/string.cpp"
>> >  Then, this problem can be fixed.
>> >
>> >  I'm not sure why gdb does not give a cannical filename, but still leaves
>> >  the "../../" in the result.
> Because the function that canonicalizes the file name does not support
> backslashes correctly?
>

By reading the gdb source, mostly in file: source.c and symtab.c

I found that in the function:

char *
symtab_to_fullname (struct symtab *s)
{
   int r;

   if (!s)
     return NULL;

   /* Don't check s->fullname here, the file could have been
      deleted/moved/..., look for it again.  */
   r = find_and_open_source (s->filename, s->dirname, &s->fullname);

   if (r >= 0)
     {
       close (r);
       return s->fullname;
     }

   return NULL;
}

This function try to check if the file exists.

The lucky thing is: The function call:

open("D:\code\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp") ;

works OK.

Though the file path is not satisfied by me, but it just satisfied by 
open() function, Yeah, the open() function can internally do a path 
canonization on its parameter, and gdb knows that this file exists and 
can be opened.

As I know, GDB does not do a canonization on any returned file names. (I 
can't find any code snippet doing this kind of work).

Well, the proposed method can be: (see below)
char *
symtab_to_fullname (struct symtab *s)
{
   int r;

   if (!s)
     return NULL;

   /* Don't check s->fullname here, the file could have been
      deleted/moved/..., look for it again.  */
   r = find_and_open_source (s->filename, s->dirname, &s->fullname);

   if (r >= 0)
     {
       close (r);
       *******
       DoSomePathCanonization(&s->fullname);
       *******
       return s->fullname;
     }

   return NULL;
}

This way, the returned string can be:
"D:/code/wxWidgets-2.8.12/src/common/string.cpp"

BTW:Did you thing that Any one would like to set a breakpoint by using 
name containing many "../../"?

I can hardly think one would like to set a break point by entering this 
command:

b "D:\code\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp:165"

I personally think this is too ugly.

Any ideas?

Asmwarrior
ollydbg from codeblocks' forum

Re: setting a breakpoint on a dll, relative path or absolute path issue

[Asm warrior]

On 2011-6-14 11:10, Asm warrior wrote:
> On 2011-6-14 0:59, Eli Zaretskii wrote:
>>> Date: Mon, 13 Jun 2011 14:29:28 +0800
>>> > From: Asm warrior<asmwarrior@gmail.com>
>>> > CC: "John E. / TDM"<tdragon@tdragon.net>, Eli Zaretskii<eliz@gnu.org>,
>>> > jan.kratochvil@redhat.com,keiths@redhat.com
>>> >
>>> > When loop on the symbols. I found that at one loop, I get
>>> >
>>> > s->filename = "../../src/common/string.cpp"
>>> > s->dirname = "D:\code\wxWidgets-2.8.12\build\msw"
>>> >
>>> > But too badly, the result
>>> > s->fullname =
>>> > "D:\code\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp"
>>> >
>>> > This is the reason about the issue, if the result is:
>>> > "D:\code\wxWidgets-2.8.12/src/common/string.cpp"
>>> > Then, this problem can be fixed.
>>> >
>>> > I'm not sure why gdb does not give a cannical filename, but still
>>> leaves
>>> > the "../../" in the result.
>> Because the function that canonicalizes the file name does not support
>> backslashes correctly?
>>
>
> By reading the gdb source, mostly in file: source.c and symtab.c
>
> I found that in the function:
>
> char *
> symtab_to_fullname (struct symtab *s)
> {
> int r;
>
> if (!s)
> return NULL;
>
> /* Don't check s->fullname here, the file could have been
> deleted/moved/..., look for it again. */
> r = find_and_open_source (s->filename, s->dirname, &s->fullname);
>
> if (r >= 0)
> {
> close (r);
> return s->fullname;
> }
>
> return NULL;
> }
>
> This function try to check if the file exists.
>
> The lucky thing is: The function call:
>
> open("D:\code\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp") ;
>
> works OK.
>
> Though the file path is not satisfied by me, but it just satisfied by
> open() function, Yeah, the open() function can internally do a path
> canonization on its parameter, and gdb knows that this file exists and
> can be opened.
>
> As I know, GDB does not do a canonization on any returned file names. (I
> can't find any code snippet doing this kind of work).
>
> Well, the proposed method can be: (see below)
> char *
> symtab_to_fullname (struct symtab *s)
> {
> int r;
>
> if (!s)
> return NULL;
>
> /* Don't check s->fullname here, the file could have been
> deleted/moved/..., look for it again. */
> r = find_and_open_source (s->filename, s->dirname, &s->fullname);
>
> if (r >= 0)
> {
> close (r);
> *******
> DoSomePathCanonization(&s->fullname);
> *******
> return s->fullname;
> }
>
> return NULL;
> }
>
> This way, the returned string can be:
> "D:/code/wxWidgets-2.8.12/src/common/string.cpp"
>
> BTW:Did you thing that Any one would like to set a breakpoint by using
> name containing many "../../"?
>
> I can hardly think one would like to set a break point by entering this
> command:
>
> b "D:\code\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp:165"
>
> I personally think this is too ugly.
>
> Any ideas?
>
> Asmwarrior
> ollydbg from codeblocks' forum
>

Ok, now I try to implement this, I found the is a function do the 
canonicalize filepath.

under gdb\utils.c

char *
gdb_realpath (const char *filename)
{
   /* Method 1: The system has a compile time upper bound on a filename
      path.  Use that and realpath() to canonicalize the name.  This is
      the most common case.  Note that, if there isn't a compile time
      upper bound, you want to avoid realpath() at all costs.  */
#if defined(HAVE_REALPATH)
   {
# if defined (PATH_MAX)
     char buf[PATH_MAX];
#  define USE_REALPATH
# elif defined (MAXPATHLEN)
     char buf[MAXPATHLEN];
#  define USE_REALPATH
# endif
# if defined (USE_REALPATH)
     const char *rp = realpath (filename, buf);

     if (rp == NULL)
       rp = filename;
     return xstrdup (rp);
# endif
   }
#endif /* HAVE_REALPATH */

   /* Method 2: The host system (i.e., GNU) has the function
      canonicalize_file_name() which malloc's a chunk of memory and
      returns that, use that.  */
#if defined(HAVE_CANONICALIZE_FILE_NAME)
   {
     char *rp = canonicalize_file_name (filename);

     if (rp == NULL)
       return xstrdup (filename);
     else
       return rp;
   }
#endif

   /* FIXME: cagney/2002-11-13:

      Method 2a: Use realpath() with a NULL buffer.  Some systems, due
      to the problems described in method 3, have modified their
      realpath() implementation so that it will allocate a buffer when
      NULL is passed in.  Before this can be used, though, some sort of
      configure time test would need to be added.  Otherwize the code
      will likely core dump.  */

   /* Method 3: Now we're getting desperate!  The system doesn't have a
      compile time buffer size and no alternative function.  Query the
      OS, using pathconf(), for the buffer limit.  Care is needed
      though, some systems do not limit PATH_MAX (return -1 for
      pathconf()) making it impossible to pass a correctly sized buffer
      to realpath() (it could always overflow).  On those systems, we
      skip this.  */
#if defined (HAVE_REALPATH) && defined (HAVE_UNISTD_H) && 
defined(HAVE_ALLOCA)
   {
     /* Find out the max path size.  */
     long path_max = pathconf ("/", _PC_PATH_MAX);

     if (path_max > 0)
       {
	/* PATH_MAX is bounded.  */
	char *buf = alloca (path_max);
	char *rp = realpath (filename, buf);

	return xstrdup (rp ? rp : filename);
       }
   }
#endif

   /* This system is a lost cause, just dup the buffer.  */
   return xstrdup (filename);
}


But I found another function in:
gdb\libiberty\lrealpath.c

char *
lrealpath (const char *filename)
{
   /* Method 1: The system has a compile time upper bound on a filename
      path.  Use that and realpath() to canonicalize the name.  This is
      the most common case.  Note that, if there isn't a compile time
      upper bound, you want to avoid realpath() at all costs.  */
#if defined(REALPATH_LIMIT)
   {
     char buf[REALPATH_LIMIT];
     const char *rp = realpath (filename, buf);
     if (rp == NULL)
       rp = filename;
     return strdup (rp);
   }
#endif /* REALPATH_LIMIT */

   /* Method 2: The host system (i.e., GNU) has the function
      canonicalize_file_name() which malloc's a chunk of memory and
      returns that, use that.  */
#if defined(HAVE_CANONICALIZE_FILE_NAME)
   {
     char *rp = canonicalize_file_name (filename);
     if (rp == NULL)
       return strdup (filename);
     else
       return rp;
   }
#endif

   /* Method 3: Now we're getting desperate!  The system doesn't have a
      compile time buffer size and no alternative function.  Query the
      OS, using pathconf(), for the buffer limit.  Care is needed
      though, some systems do not limit PATH_MAX (return -1 for
      pathconf()) making it impossible to pass a correctly sized buffer
      to realpath() (it could always overflow).  On those systems, we
      skip this.  */
#if defined (HAVE_REALPATH) && defined (HAVE_UNISTD_H)
   {
     /* Find out the max path size.  */
     long path_max = pathconf ("/", _PC_PATH_MAX);
     if (path_max > 0)
       {
	/* PATH_MAX is bounded.  */
	char *buf, *rp, *ret;
	buf = (char *) malloc (path_max);
	if (buf == NULL)
	  return NULL;
	rp = realpath (filename, buf);
	ret = strdup (rp ? rp : filename);
	free (buf);
	return ret;
       }
   }
#endif

   /* The MS Windows method.  If we don't have realpath, we assume we
      don't have symlinks and just canonicalize to a Windows absolute
      path.  GetFullPath converts ../ and ./ in relative paths to
      absolute paths, filling in current drive if one is not given
      or using the current directory of a specified drive (eg, "E:foo").
      It also converts all forward slashes to back slashes.  */
#if defined (_WIN32)
   {
     char buf[MAX_PATH];
     char* basename;
     DWORD len = GetFullPathName (filename, MAX_PATH, buf, &basename);
     if (len == 0 || len > MAX_PATH - 1)
       return strdup (filename);
     else
       {
	/* The file system is case-preserving but case-insensitive,
	   Canonicalize to lowercase, using the codepage associated
	   with the process locale.  */
         CharLowerBuff (buf, len);
         return strdup (buf);
       }
   }
#endif

   /* This system is a lost cause, just duplicate the filename.  */
   return strdup (filename);
}

-------------------------------------------------------

Did you think we should add the "MS Windows method." in 
gdb\libiberty\lrealpath.c to the char * gdb_realpath (const char 
*filename) function body?

As currently, it just do a strdup(filename) under MinGW32 (Windows).


asmwarrior
ollydbg from codeblocks' forum

Re: setting a breakpoint on a dll, relative path or absolute path issue

[Jeffrey Walton]

On Mon, Jun 13, 2011 at 11:45 PM, Asm warrior <asmwarrior@gmail.com> wrote:
> On 2011-6-14 11:10, Asm warrior wrote:
>>
>> On 2011-6-14 0:59, Eli Zaretskii wrote:
>>>>
>>>> Date: Mon, 13 Jun 2011 14:29:28 +0800
>>>> > From: Asm warrior<asmwarrior@gmail.com>
>>>> > CC: "John E. / TDM"<tdragon@tdragon.net>, Eli Zaretskii<eliz@gnu.org>,
>>>> > jan.kratochvil@redhat.com,keiths@redhat.com
>>>> >
>>>> > When loop on the symbols. I found that at one loop, I get
>>>> >
>>>> > s->filename = "../../src/common/string.cpp"
>>>> > s->dirname = "D:\code\wxWidgets-2.8.12\build\msw"
>>>> >
>>>> > But too badly, the result
>>>> > s->fullname =
>>>> > "D:\code\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp"
>>>> >
>>>> > This is the reason about the issue, if the result is:
>>>> > "D:\code\wxWidgets-2.8.12/src/common/string.cpp"
>>>> > Then, this problem can be fixed.
>>>> >
>>>> > I'm not sure why gdb does not give a cannical filename, but still
>>>> leaves
>>>> > the "../../" in the result.
>>>
>>> Because the function that canonicalizes the file name does not support
>>> backslashes correctly?
>>>
>>
>> By reading the gdb source, mostly in file: source.c and symtab.c
>>
>> char buf[MAX_PATH];
>> char* basename;
>> DWORD len = GetFullPathName (filename, MAX_PATH, buf, &basename);
>> ...
From experience, I've found that using MAX_PATH*2 is useful. Its not
uncommon to have a few directories added to a user's temp directory
and exceed MAX_PATH. It will help keep you out of:

>> if (len == 0 || len > MAX_PATH - 1)
>>     return strdup (filename);

From experience, I've never encountered a valid case for MAX_PATH*3.
While possibly a valid length, I consider anything greater than
MAX_PATH*2 an attack.

>> [SNIP]

> Did you think we should add the "MS Windows method." in
> gdb\libiberty\lrealpath.c to the char * gdb_realpath (const char *filename)
> function body?
For what its worth, Microsoft has moved to the Consolidated URL Parser
(cURL) for path normalization and canonicalization. See, for example,
CreateUri Function [1] and ParseURL Function [2]. Howard and LeBlanc
recommend their use in Writing Secure Code for Windows Vista (pp.
130-131).

> As currently, it just do a strdup(filename) under MinGW32 (Windows).

Jeff

[1] http://msdn.microsoft.com/en-us/library/ms775098(v=vs.85).aspx
[2] http://msdn.microsoft.com/en-us/library/bb773825(v=vs.85).aspx

Re: setting a breakpoint on a dll, relative path or absolute path issue[solved with a patch]

[asmwarrior]

Sounds like I have fix this problem by using the patches below.
(I'm sorry I'm only a beginner of git, so correct me if I'm wrong)




  gdb/linespec.c |    3 ++-
  gdb/source.c   |   48 +++++++++++++++++++++++++++---------------------
  gdb/utils.c    |   24 ++++++++++++++++++++++++
  3 files changed, 53 insertions(+), 22 deletions(-)

diff --git a/gdb/linespec.c b/gdb/linespec.c
index c820539..c8251c5 100644
--- a/gdb/linespec.c
+++ b/gdb/linespec.c
@@ -1211,7 +1211,8 @@ locate_first_half (char **argptr, int 
*is_quote_enclosed)
       quotes we do not break on enclosed spaces.  */
        if (!*p
        || p[0] == '\t'
-      || (p[0] == ':')
+      || ((p[0] == ':')
+ && ((p[1] == ':') || (strchr (p + 1, ':') == NULL)))
        || ((p[0] == ' ') && !*is_quote_enclosed))
      break;
        if (p[0] == '.' && strchr (p, ':') == NULL)
diff --git a/gdb/source.c b/gdb/source.c
index 70890e1..77dc249 100644
--- a/gdb/source.c
+++ b/gdb/source.c
@@ -149,7 +149,7 @@ get_lines_to_list (void)

  /* Return the current source file for listing and next line to list.
     NOTE: The returned sal pc and end fields are not valid.  */
-
+
  struct symtab_and_line
  get_current_source_symtab_and_line (void)
  {
@@ -160,7 +160,7 @@ get_current_source_symtab_and_line (void)
    cursal.line = current_source_line;
    cursal.pc = 0;
    cursal.end = 0;
-
+
    return cursal;
  }

@@ -171,7 +171,7 @@ get_current_source_symtab_and_line (void)
     process of determining a new default may call the caller!
     Use get_current_source_symtab_and_line only to get whatever
     we have without erroring out or trying to get a default.  */
-
+
  void
  set_default_source_symtab_and_line (void)
  {
@@ -187,7 +187,7 @@ set_default_source_symtab_and_line (void)
     (the returned sal pc and end fields are not valid.)
     and set the current default to whatever is in SAL.
     NOTE: The returned sal pc and end fields are not valid.  */
-
+
  struct symtab_and_line
  set_current_source_symtab_and_line (const struct symtab_and_line *sal)
  {
@@ -702,7 +702,7 @@ is_regular_file (const char *name)
     the actual file opened (this string will always start with a "/").  We
     have to take special pains to avoid doubling the "/" between the 
directory
     and the file, sigh!  Emacs gets confuzzed by this when we print the
-   source file name!!!
+   source file name!!!

     If a file is found, return the descriptor.
     Otherwise, return -1, with errno set for the last name we tried to 
open.  */
@@ -924,7 +924,7 @@ substitute_path_rule_matches (const struct 
substitute_path_rule *rule,
    /* Make sure that the region in the path that matches the substitution
       rule is immediately followed by a directory separator (or the end of
       string character).  */
-
+
    if (path[from_len] != '\0' && !IS_DIR_SEPARATOR (path[from_len]))
      return 0;

@@ -948,17 +948,17 @@ get_substitute_path_rule (const char *path)
  /* If the user specified a source path substitution rule that applies
     to PATH, then apply it and return the new path.  This new path must
     be deallocated afterwards.
-
+
     Return NULL if no substitution rule was specified by the user,
     or if no rule applied to the given PATH.  */
-
+
  static char *
  rewrite_source_path (const char *path)
  {
    const struct substitute_path_rule *rule = get_substitute_path_rule 
(path);
    char *new_path;
    int from_len;
-
+
    if (rule == NULL)
      return NULL;

@@ -985,7 +985,7 @@ rewrite_source_path (const char *path)
       Space for the path must have been malloc'd.  If a path substitution
       is applied we free the old value and set a new one.

-   On Success
+   On Success
       A valid file descriptor is returned (the return value is positive).
       FULLNAME is set to the absolute path to the file just opened.
       The caller is responsible for freeing FULLNAME.
@@ -1002,6 +1002,7 @@ find_and_open_source (const char *filename,
    char *path = source_path;
    const char *p;
    int result;
+  char *lpath;

    /* Quick way out if we already know its full name.  */

@@ -1010,7 +1011,7 @@ find_and_open_source (const char *filename,
        /* The user may have requested that source paths be rewritten
           according to substitution rules he provided.  If a substitution
           rule applies to this path, then apply it.  */
-      char *rewritten_fullname = rewrite_source_path (*fullname);
+      char *rewritten_fullname = rewrite_source_path (*fullname);

        if (rewritten_fullname != NULL)
          {
@@ -1020,7 +1021,12 @@ find_and_open_source (const char *filename,

        result = open (*fullname, OPEN_MODE);
        if (result >= 0)
-    return result;
+      {
+        lpath = gdb_realpath(*fullname);
+        xfree(*fullname);
+        *fullname = lpath;
+        return result;
+      }
        /* Didn't work -- free old one, try again.  */
        xfree (*fullname);
        *fullname = NULL;
@@ -1038,7 +1044,7 @@ find_and_open_source (const char *filename,
            make_cleanup (xfree, rewritten_dirname);
            dirname = rewritten_dirname;
          }
-
+
        /* Replace a path entry of $cdir with the compilation directory
       name.  */
  #define    cdir_len    5
@@ -1072,7 +1078,7 @@ find_and_open_source (const char *filename,
            filename = rewritten_filename;
          }
      }
-
+
    result = openp (path, OPF_SEARCH_IN_PATH, filename, OPEN_MODE, 
fullname);
    if (result < 0)
      {
@@ -1086,8 +1092,8 @@ find_and_open_source (const char *filename,
  }

  /* Open a source file given a symtab S.  Returns a file descriptor or
-   negative number for error.
-
+   negative number for error.
+
     This function is a convience function to find_and_open_source.  */

  int
@@ -1159,7 +1165,7 @@ find_source_lines (struct symtab *s, int desc)
    {
      struct cleanup *old_cleanups;

-    /* st_size might be a large type, but we only support source files 
whose
+    /* st_size might be a large type, but we only support source files 
whose
         size fits in an int.  */
      size = (int) st.st_size;

@@ -1773,7 +1779,7 @@ show_substitute_path_command (char *args, int 
from_tty)
    struct substitute_path_rule *rule = substitute_path_rules;
    char **argv;
    char *from = NULL;
-
+
    argv = gdb_buildargv (args);
    make_cleanup_freeargv (argv);

@@ -1843,7 +1849,7 @@ unset_substitute_path_command (char *args, int 
from_tty)

        rule = next;
      }
-
+
    /* If the user asked for a specific rule to be deleted but
       we could not find it, then report an error.  */

@@ -1860,7 +1866,7 @@ set_substitute_path_command (char *args, int from_tty)
  {
    char **argv;
    struct substitute_path_rule *rule;
-
+
    argv = gdb_buildargv (args);
    make_cleanup_freeargv (argv);

@@ -1884,7 +1890,7 @@ set_substitute_path_command (char *args, int from_tty)
    rule = find_substitute_path_rule (argv[0]);
    if (rule != NULL)
      delete_substitute_path_rule (rule);
-
+
    /* Insert the new substitution rule.  */

    add_substitute_path_rule (argv[0], argv[1]);
diff --git a/gdb/utils.c b/gdb/utils.c
index d10669a..14944da 100644
--- a/gdb/utils.c
+++ b/gdb/utils.c
@@ -3442,6 +3442,30 @@ gdb_realpath (const char *filename)
    }
  #endif

+  /* The MS Windows method.  If we don't have realpath, we assume we
+     don't have symlinks and just canonicalize to a Windows absolute
+     path.  GetFullPath converts ../ and ./ in relative paths to
+     absolute paths, filling in current drive if one is not given
+     or using the current directory of a specified drive (eg, "E:foo").
+     It also converts all forward slashes to back slashes.  */
+#if defined (_WIN32)
+  {
+    char buf[MAX_PATH];
+    char* basename;
+    DWORD len = GetFullPathName (filename, MAX_PATH, buf, &basename);
+    if (len == 0 || len > MAX_PATH - 1)
+      return xstrdup (filename);
+    else
+      {
+    /* The file system is case-preserving but case-insensitive,
+       Canonicalize to lowercase, using the codepage associated
+       with the process locale.  */
+        CharLowerBuff (buf, len);
+        return xstrdup (buf);
+      }
+  }
+#endif
+
    /* This system is a lost cause, just dup the buffer.  */
    return xstrdup (filename);
  }



asmwarrior
ollydbg from codeblocks' forum