* 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: [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
[parent not found: <4DF37ADA.3070905@users.sourceforge.net>]
* 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
[parent not found: <4DF4513A.3090902__7466.60719528354$1307866544$gmane$org@gmail.com>]
* 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).