From: asmwarrior <asm...@gm...> - 2011-06-11 07:49:48
|
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 |
From: Rsp <ara...@ya...> - 2011-06-11 11:57:12
|
for this and other reasons I abandoned gdb a few years ago --- Em sáb, 11/6/11, asmwarrior <asm...@gm...> escreveu: > De: asmwarrior <asm...@gm...> > Assunto: [Mingw-users] setting a breakpoint on a dll, relative path or absolute path issue > Para: gd...@so..., "MinGW Users List" <min...@li...> > Data: Sábado, 11 de Junho de 2011, 4:52 > 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 > > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically > advanced content > authoring tool. Experience the power of Track Changes, > Inline Image > Editing and ensure content is compliant with Accessibility > Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard > for the list etiquette may cause your account to be > moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe > at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > |
From: Earnie <ea...@us...> - 2011-06-11 14:25:40
|
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? > 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. -- Earnie -- http://www.for-my-kids.com |
From: asmwarrior <asm...@gm...> - 2011-06-12 05:37:44
|
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 |
From: asmwarrior <asm...@gm...> - 2011-06-12 03:56:10
|
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 |
From: asmwarrior <asm...@gm...> - 2011-06-12 07:45:12
|
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 |
From: asmwarrior <asm...@gm...> - 2011-06-12 07:45:04
|
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 |
From: asmwarrior <asm...@gm...> - 2011-06-12 08:06:43
|
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 |
From: Earnie <ea...@us...> - 2011-06-12 16:22:25
|
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 |
From: Keith M. <kei...@us...> - 2011-06-13 18:44:52
|
Responding to an (apparently) cross-posted message, I am *not* doing likewise; OP, please ensure that you summarise for the benefit of those on your original recipient list who are not MinGW-Users subscribers. On 12/06/11 09:09, 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. No, this is not strictly correct. The MS file system considers '\' and '/' as equivalent within path names, (although there are one or two places within Microsoft's APIs where they fail to honour this equivalence). MinGW simply assumes that user code will DTRT, and makes no particular effort to translate in either direction. IMO, it is a bug in GDB if it is comparing MSW path name strings without honouring the canonical '\' == '/' equivalence. -- Regards, Keith. |
From: John E. / T. <td...@td...> - 2011-06-12 14:29:38
|
On 6/12/2011 1:47 AM, asmwarrior wrote: > 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. TDM-GCC has a patch for GCC (headerpath.patch; somewhat a misnomer perhaps) that I believe solves this problem, if you're interested. -John E. / TDM |
From: asmwarrior <asm...@gm...> - 2011-06-13 04:38:43
|
On 2011-6-12 22:29, John E. / TDM wrote: > On 6/12/2011 1:47 AM, asmwarrior wrote: >> 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. > > TDM-GCC has a patch for GCC (headerpath.patch; somewhat a misnomer > perhaps) that I believe solves this problem, if you're interested. > > -John E. / TDM Thanks John, I will look into it. Did you mean that if "E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/datetime.cpp" were saved as "E:/code/cb/wx/wxWidgets-2.8.12/build/msw/../../src/common/datetime.cpp" The the problem may be fixed? thanks. asmwarrior ollydbg from codeblocks' forum |
From: Asm w. <asm...@gm...> - 2011-06-13 06:33:12
|
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 |
From: asmwarrior <asm...@gm...> - 2011-06-14 05:27:12
|
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 |