* setting a breakpoint on a dll, relative path or absolute path issue
@ 2011-06-11 7:49 asmwarrior
2011-06-11 17:56 ` Keith Seitz
[not found] ` <4DF37ADA.3070905@users.sourceforge.net>
0 siblings, 2 replies; 16+ messages in thread
From: asmwarrior @ 2011-06-11 7:49 UTC (permalink / raw)
To: gdb, MinGW Users List
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: setting a breakpoint on a dll, relative path or absolute path issue
2011-06-11 7:49 setting a breakpoint on a dll, relative path or absolute path issue asmwarrior
@ 2011-06-11 17:56 ` Keith Seitz
2011-06-12 3:56 ` asmwarrior
[not found] ` <4DF37ADA.3070905@users.sourceforge.net>
1 sibling, 1 reply; 16+ messages in thread
From: Keith Seitz @ 2011-06-11 17:56 UTC (permalink / raw)
To: asmwarrior; +Cc: gdb, MinGW Users List
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: setting a breakpoint on a dll, relative path or absolute path issue
2011-06-11 17:56 ` Keith Seitz
@ 2011-06-12 3:56 ` asmwarrior
2011-06-12 7:45 ` asmwarrior
0 siblings, 1 reply; 16+ messages in thread
From: asmwarrior @ 2011-06-12 3:56 UTC (permalink / raw)
To: Keith Seitz; +Cc: gdb, MinGW Users List
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: setting a breakpoint on a dll, relative path or absolute path issue
2011-06-12 3:56 ` asmwarrior
@ 2011-06-12 7:45 ` asmwarrior
2011-06-12 7:56 ` Jan Kratochvil
0 siblings, 1 reply; 16+ messages in thread
From: asmwarrior @ 2011-06-12 7:45 UTC (permalink / raw)
To: Keith Seitz; +Cc: gdb, MinGW Users List
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: setting a breakpoint on a dll, relative path or absolute path issue
2011-06-12 7:45 ` asmwarrior
@ 2011-06-12 7:56 ` Jan Kratochvil
2011-06-12 8:06 ` asmwarrior
2011-06-12 16:51 ` Eli Zaretskii
0 siblings, 2 replies; 16+ messages in thread
From: Jan Kratochvil @ 2011-06-12 7:56 UTC (permalink / raw)
To: asmwarrior; +Cc: Keith Seitz, gdb, MinGW Users List
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: setting a breakpoint on a dll, relative path or absolute path issue
2011-06-12 7:56 ` Jan Kratochvil
@ 2011-06-12 8:06 ` asmwarrior
2011-06-12 16:22 ` [Mingw-users] " Earnie
2011-06-12 16:51 ` Eli Zaretskii
1 sibling, 1 reply; 16+ messages in thread
From: asmwarrior @ 2011-06-12 8:06 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: Keith Seitz, gdb, MinGW Users List
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: setting a breakpoint on a dll, relative path or absolute path issue
[not found] ` <4DF37ADA.3070905@users.sourceforge.net>
@ 2011-06-12 8:15 ` asmwarrior
[not found] ` <4DF4513A.3090902__7466.60719528354$1307866544$gmane$org@gmail.com>
1 sibling, 0 replies; 16+ messages in thread
From: asmwarrior @ 2011-06-12 8:15 UTC (permalink / raw)
To: MinGW Users List, gdb
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Mingw-users] setting a breakpoint on a dll, relative path or absolute path issue
2011-06-12 8:06 ` asmwarrior
@ 2011-06-12 16:22 ` Earnie
0 siblings, 0 replies; 16+ messages in thread
From: Earnie @ 2011-06-12 16:22 UTC (permalink / raw)
To: MinGW Users List; +Cc: asmwarrior, Jan Kratochvil, Keith Seitz, gdb
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: setting a breakpoint on a dll, relative path or absolute path issue
2011-06-12 7:56 ` Jan Kratochvil
2011-06-12 8:06 ` asmwarrior
@ 2011-06-12 16:51 ` Eli Zaretskii
2011-06-12 16:54 ` Jan Kratochvil
1 sibling, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2011-06-12 16:51 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: asmwarrior, keiths, gdb, mingw-users
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: setting a breakpoint on a dll, relative path or absolute path issue
2011-06-12 16:51 ` Eli Zaretskii
@ 2011-06-12 16:54 ` Jan Kratochvil
0 siblings, 0 replies; 16+ messages in thread
From: Jan Kratochvil @ 2011-06-12 16:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: asmwarrior, keiths, gdb, mingw-users
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: setting a breakpoint on a dll, relative path or absolute path issue
[not found] ` <4DF4513A.3090902__7466.60719528354$1307866544$gmane$org@gmail.com>
@ 2011-06-13 6:33 ` Asm warrior
2011-06-13 17:02 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Asm warrior @ 2011-06-13 6:33 UTC (permalink / raw)
To: MinGW Users List, gdb
Cc: John E. / TDM, Eli Zaretskii, jan.kratochvil, keiths
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: setting a breakpoint on a dll, relative path or absolute path issue
2011-06-13 6:33 ` Asm warrior
@ 2011-06-13 17:02 ` Eli Zaretskii
2011-06-14 3:14 ` Asm warrior
2011-06-14 5:27 ` setting a breakpoint on a dll, relative path or absolute path issue[solved with a patch] asmwarrior
0 siblings, 2 replies; 16+ messages in thread
From: Eli Zaretskii @ 2011-06-13 17:02 UTC (permalink / raw)
To: Asm warrior; +Cc: gdb, tdragon, jan.kratochvil, keiths
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: setting a breakpoint on a dll, relative path or absolute path issue
2011-06-13 17:02 ` Eli Zaretskii
@ 2011-06-14 3:14 ` Asm warrior
2011-06-14 3:49 ` Asm warrior
2011-06-14 5:27 ` setting a breakpoint on a dll, relative path or absolute path issue[solved with a patch] asmwarrior
1 sibling, 1 reply; 16+ messages in thread
From: Asm warrior @ 2011-06-14 3:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: setting a breakpoint on a dll, relative path or absolute path issue
2011-06-14 3:14 ` Asm warrior
@ 2011-06-14 3:49 ` Asm warrior
2011-06-14 4:22 ` Jeffrey Walton
0 siblings, 1 reply; 16+ messages in thread
From: Asm warrior @ 2011-06-14 3:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: setting a breakpoint on a dll, relative path or absolute path issue
2011-06-14 3:49 ` Asm warrior
@ 2011-06-14 4:22 ` Jeffrey Walton
0 siblings, 0 replies; 16+ messages in thread
From: Jeffrey Walton @ 2011-06-14 4:22 UTC (permalink / raw)
To: Asm warrior; +Cc: gdb
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: setting a breakpoint on a dll, relative path or absolute path issue[solved with a patch]
2011-06-13 17:02 ` Eli Zaretskii
2011-06-14 3:14 ` Asm warrior
@ 2011-06-14 5:27 ` asmwarrior
1 sibling, 0 replies; 16+ messages in thread
From: asmwarrior @ 2011-06-14 5:27 UTC (permalink / raw)
To: gdb, MinGW Users List
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
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2011-06-14 5:27 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-11 7:49 setting a breakpoint on a dll, relative path or absolute path issue asmwarrior
2011-06-11 17:56 ` Keith Seitz
2011-06-12 3:56 ` asmwarrior
2011-06-12 7:45 ` asmwarrior
2011-06-12 7:56 ` Jan Kratochvil
2011-06-12 8:06 ` asmwarrior
2011-06-12 16:22 ` [Mingw-users] " Earnie
2011-06-12 16:51 ` Eli Zaretskii
2011-06-12 16:54 ` Jan Kratochvil
[not found] ` <4DF37ADA.3070905@users.sourceforge.net>
2011-06-12 8:15 ` asmwarrior
[not found] ` <4DF4513A.3090902__7466.60719528354$1307866544$gmane$org@gmail.com>
2011-06-13 6:33 ` Asm warrior
2011-06-13 17:02 ` Eli Zaretskii
2011-06-14 3:14 ` Asm warrior
2011-06-14 3:49 ` Asm warrior
2011-06-14 4:22 ` Jeffrey Walton
2011-06-14 5:27 ` setting a breakpoint on a dll, relative path or absolute path issue[solved with a patch] asmwarrior
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).