* How to set a breakpoint on imported Win32 function? @ 2020-01-15 22:42 Ruslan Kabatsayev 2020-01-16 14:54 ` Luis Machado 0 siblings, 1 reply; 8+ messages in thread From: Ruslan Kabatsayev @ 2020-01-15 22:42 UTC (permalink / raw) To: gdb Hello, I have a program without any debug info, which has an import table with some functions imported by name. E.g. kernel32!ExitProcess is imported, and the debugger should know its name and address. But whenever I run GDB (from mingw-w64) with my test exe and try to set breakpoint on ExitProcess, GDB complains that no symbol table is loaded and asks if I want it set on future library load. After I agree and let the debuggee run, the debuggee exits without any trap (although it does exit via this exact function). OTOH, on Linux I can set a breakpoint on e.g. exit, which gets located in /lib/i386-linux-gnu/libc.so.6 for which I don't have any debug symbols, and the breakpoint successfully traps. So, how can I set a breakpoint on an imported function in Windows? Or is the handling of PE import table to fill GDB's symbol table not implemented? Thanks, Ruslan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: How to set a breakpoint on imported Win32 function? 2020-01-15 22:42 How to set a breakpoint on imported Win32 function? Ruslan Kabatsayev @ 2020-01-16 14:54 ` Luis Machado 2020-01-16 17:17 ` Ruslan Kabatsayev 0 siblings, 1 reply; 8+ messages in thread From: Luis Machado @ 2020-01-16 14:54 UTC (permalink / raw) To: Ruslan Kabatsayev, gdb On 1/15/20 7:42 PM, Ruslan Kabatsayev wrote: > Hello, > > I have a program without any debug info, which has an import table > with some functions imported by name. E.g. kernel32!ExitProcess is > imported, and the debugger should know its name and address. > > But whenever I run GDB (from mingw-w64) with my test exe and try to > set breakpoint on ExitProcess, GDB complains that no symbol table is > loaded and asks if I want it set on future library load. After I agree > and let the debuggee run, the debuggee exits without any trap > (although it does exit via this exact function). > > OTOH, on Linux I can set a breakpoint on e.g. exit, which gets located > in /lib/i386-linux-gnu/libc.so.6 for which I don't have any debug > symbols, and the breakpoint successfully traps. > > So, how can I set a breakpoint on an imported function in Windows? Or > is the handling of PE import table to fill GDB's symbol table not > implemented? > > Thanks, > Ruslan > Given what you described, i think GDB doesn't know how to properly locate that symbol. Can you at least see the symbol somewhere, in disassemble output for example? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: How to set a breakpoint on imported Win32 function? 2020-01-16 14:54 ` Luis Machado @ 2020-01-16 17:17 ` Ruslan Kabatsayev 2020-01-16 18:14 ` Luis Machado 0 siblings, 1 reply; 8+ messages in thread From: Ruslan Kabatsayev @ 2020-01-16 17:17 UTC (permalink / raw) To: Luis Machado; +Cc: gdb On Thu, 16 Jan 2020 at 17:53, Luis Machado <luis.machado@linaro.org> wrote: > > On 1/15/20 7:42 PM, Ruslan Kabatsayev wrote: > > Hello, > > > > I have a program without any debug info, which has an import table > > with some functions imported by name. E.g. kernel32!ExitProcess is > > imported, and the debugger should know its name and address. > > > > But whenever I run GDB (from mingw-w64) with my test exe and try to > > set breakpoint on ExitProcess, GDB complains that no symbol table is > > loaded and asks if I want it set on future library load. After I agree > > and let the debuggee run, the debuggee exits without any trap > > (although it does exit via this exact function). > > > > OTOH, on Linux I can set a breakpoint on e.g. exit, which gets located > > in /lib/i386-linux-gnu/libc.so.6 for which I don't have any debug > > symbols, and the breakpoint successfully traps. > > > > So, how can I set a breakpoint on an imported function in Windows? Or > > is the handling of PE import table to fill GDB's symbol table not > > implemented? > > > > Thanks, > > Ruslan > > > > Given what you described, i think GDB doesn't know how to properly > locate that symbol. Can you at least see the symbol somewhere, in > disassemble output for example? No, apparently GDB doesn't indeed know about this symbol. The disassembly (both at the call site and in the function itself) simply shows the address, without any hints about symbols. Has this ever worked on Windows GDB? Or was it simply not implemented? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: How to set a breakpoint on imported Win32 function? 2020-01-16 17:17 ` Ruslan Kabatsayev @ 2020-01-16 18:14 ` Luis Machado 2020-01-16 18:28 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Luis Machado @ 2020-01-16 18:14 UTC (permalink / raw) To: Ruslan Kabatsayev; +Cc: gdb, Eli Zaretskii On 1/16/20 2:16 PM, Ruslan Kabatsayev wrote: > On Thu, 16 Jan 2020 at 17:53, Luis Machado <luis.machado@linaro.org> wrote: >> >> On 1/15/20 7:42 PM, Ruslan Kabatsayev wrote: >>> Hello, >>> >>> I have a program without any debug info, which has an import table >>> with some functions imported by name. E.g. kernel32!ExitProcess is >>> imported, and the debugger should know its name and address. >>> >>> But whenever I run GDB (from mingw-w64) with my test exe and try to >>> set breakpoint on ExitProcess, GDB complains that no symbol table is >>> loaded and asks if I want it set on future library load. After I agree >>> and let the debuggee run, the debuggee exits without any trap >>> (although it does exit via this exact function). >>> >>> OTOH, on Linux I can set a breakpoint on e.g. exit, which gets located >>> in /lib/i386-linux-gnu/libc.so.6 for which I don't have any debug >>> symbols, and the breakpoint successfully traps. >>> >>> So, how can I set a breakpoint on an imported function in Windows? Or >>> is the handling of PE import table to fill GDB's symbol table not >>> implemented? >>> >>> Thanks, >>> Ruslan >>> >> >> Given what you described, i think GDB doesn't know how to properly >> locate that symbol. Can you at least see the symbol somewhere, in >> disassemble output for example? > > No, apparently GDB doesn't indeed know about this symbol. The > disassembly (both at the call site and in the function itself) simply > shows the address, without any hints about symbols. > Has this ever worked on Windows GDB? Or was it simply not implemented? > I'm not well versed in GDB on Windows, so i'm not so sure. It could be both. I've cc-ed Eli, who tends to touch more mingw stuff. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: How to set a breakpoint on imported Win32 function? 2020-01-16 18:14 ` Luis Machado @ 2020-01-16 18:28 ` Eli Zaretskii 2020-01-16 20:01 ` Ruslan Kabatsayev 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2020-01-16 18:28 UTC (permalink / raw) To: Luis Machado; +Cc: b7.10110111, gdb > Cc: gdb@gnu.org, Eli Zaretskii <eliz@gnu.org> > From: Luis Machado <luis.machado@linaro.org> > Date: Thu, 16 Jan 2020 15:13:55 -0300 > > >>> I have a program without any debug info, which has an import table > >>> with some functions imported by name. E.g. kernel32!ExitProcess is > >>> imported, and the debugger should know its name and address. > >>> > >>> But whenever I run GDB (from mingw-w64) with my test exe and try to > >>> set breakpoint on ExitProcess, GDB complains that no symbol table is > >>> loaded and asks if I want it set on future library load. After I agree > >>> and let the debuggee run, the debuggee exits without any trap > >>> (although it does exit via this exact function). > >>> > >>> OTOH, on Linux I can set a breakpoint on e.g. exit, which gets located > >>> in /lib/i386-linux-gnu/libc.so.6 for which I don't have any debug > >>> symbols, and the breakpoint successfully traps. > >>> > >>> So, how can I set a breakpoint on an imported function in Windows? Or > >>> is the handling of PE import table to fill GDB's symbol table not > >>> implemented? > >>> > >>> Thanks, > >>> Ruslan > >>> > >> > >> Given what you described, i think GDB doesn't know how to properly > >> locate that symbol. Can you at least see the symbol somewhere, in > >> disassemble output for example? > > > > No, apparently GDB doesn't indeed know about this symbol. The > > disassembly (both at the call site and in the function itself) simply > > shows the address, without any hints about symbols. > > Has this ever worked on Windows GDB? Or was it simply not implemented? > > > > I'm not well versed in GDB on Windows, so i'm not so sure. It could be both. > > I've cc-ed Eli, who tends to touch more mingw stuff. I'll try to help, although I don't think understand well enough the use case. If I start a MinGW program under GDB, and then put a breakpoint on ExitProcess, I get this: Temporary breakpoint 2, main (argc=2, argv=0xa42848) at emacs.c:934 934 bool no_loadup = false; (gdb) break ExitProcess Breakpoint 3 at 0x7c81bfa7 (gdb) info breakpoints Num Type Disp Enb Address What 3 breakpoint keep y 0x7c81bfa7 <KERNEL32!ExitProcess+5> So it seems that GDB already knows how to put breakpoints on such functions: you just need to name them without the DLL-name part. However, I'm not sure I understand what is meant above by "functions imported by name". How exactly were they imported? Does the above technique work for you? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: How to set a breakpoint on imported Win32 function? 2020-01-16 18:28 ` Eli Zaretskii @ 2020-01-16 20:01 ` Ruslan Kabatsayev 2020-01-17 7:46 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Ruslan Kabatsayev @ 2020-01-16 20:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Luis Machado, gdb On Thu, 16 Jan 2020 at 21:28, Eli Zaretskii <eliz@gnu.org> wrote: > > > Cc: gdb@gnu.org, Eli Zaretskii <eliz@gnu.org> > > From: Luis Machado <luis.machado@linaro.org> > > Date: Thu, 16 Jan 2020 15:13:55 -0300 > > > > >>> I have a program without any debug info, which has an import table > > >>> with some functions imported by name. E.g. kernel32!ExitProcess is > > >>> imported, and the debugger should know its name and address. > > >>> > > >>> But whenever I run GDB (from mingw-w64) with my test exe and try to > > >>> set breakpoint on ExitProcess, GDB complains that no symbol table is > > >>> loaded and asks if I want it set on future library load. After I agree > > >>> and let the debuggee run, the debuggee exits without any trap > > >>> (although it does exit via this exact function). > > >>> > > >>> OTOH, on Linux I can set a breakpoint on e.g. exit, which gets located > > >>> in /lib/i386-linux-gnu/libc.so.6 for which I don't have any debug > > >>> symbols, and the breakpoint successfully traps. > > >>> > > >>> So, how can I set a breakpoint on an imported function in Windows? Or > > >>> is the handling of PE import table to fill GDB's symbol table not > > >>> implemented? > > >>> > > >>> Thanks, > > >>> Ruslan > > >>> > > >> > > >> Given what you described, i think GDB doesn't know how to properly > > >> locate that symbol. Can you at least see the symbol somewhere, in > > >> disassemble output for example? > > > > > > No, apparently GDB doesn't indeed know about this symbol. The > > > disassembly (both at the call site and in the function itself) simply > > > shows the address, without any hints about symbols. > > > Has this ever worked on Windows GDB? Or was it simply not implemented? > > > > > > > I'm not well versed in GDB on Windows, so i'm not so sure. It could be both. > > > > I've cc-ed Eli, who tends to touch more mingw stuff. > > I'll try to help, although I don't think understand well enough the > use case. > > If I start a MinGW program under GDB, and then put a breakpoint on > ExitProcess, I get this: > > Temporary breakpoint 2, main (argc=2, argv=0xa42848) at emacs.c:934 > 934 bool no_loadup = false; > (gdb) break ExitProcess > Breakpoint 3 at 0x7c81bfa7 > (gdb) info breakpoints > Num Type Disp Enb Address What > 3 breakpoint keep y 0x7c81bfa7 <KERNEL32!ExitProcess+5> > > So it seems that GDB already knows how to put breakpoints on such > functions: you just need to name them without the DLL-name part. > However, I'm not sure I understand what is meant above by "functions > imported by name". How exactly were they imported? Does the above > technique work for you? They were imported as named functions usually are, i.e. not by ordinal. I just said this to emphasize that GDB should be able to find these symbols. Anyway, on my current system I've been unable to reproduce the issue (although it easily reproduces with Wine, but that's likely Wine's problem), so I'll try again when I get to the machine where the problem happened. Might have been a stupid misspelling or something else though, so I'm not sure if I'll reproduce it. Thanks for your help. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: How to set a breakpoint on imported Win32 function? 2020-01-16 20:01 ` Ruslan Kabatsayev @ 2020-01-17 7:46 ` Eli Zaretskii 2020-01-17 8:41 ` Ruslan Kabatsayev 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2020-01-17 7:46 UTC (permalink / raw) To: Ruslan Kabatsayev; +Cc: luis.machado, gdb > From: Ruslan Kabatsayev <b7.10110111@gmail.com> > Date: Thu, 16 Jan 2020 23:00:04 +0300 > Cc: Luis Machado <luis.machado@linaro.org>, gdb@gnu.org > > > If I start a MinGW program under GDB, and then put a breakpoint on > > ExitProcess, I get this: > > > > Temporary breakpoint 2, main (argc=2, argv=0xa42848) at emacs.c:934 > > 934 bool no_loadup = false; > > (gdb) break ExitProcess > > Breakpoint 3 at 0x7c81bfa7 > > (gdb) info breakpoints > > Num Type Disp Enb Address What > > 3 breakpoint keep y 0x7c81bfa7 <KERNEL32!ExitProcess+5> > > > > So it seems that GDB already knows how to put breakpoints on such > > functions: you just need to name them without the DLL-name part. > > However, I'm not sure I understand what is meant above by "functions > > imported by name". How exactly were they imported? Does the above > > technique work for you? > > They were imported as named functions usually are, i.e. not by > ordinal. I just said this to emphasize that GDB should be able to find > these symbols. Doesn't the fact that "break ExitProcess" works mean GDB _is_ able to find the symbol? Maybe I'm missing something, but I always considered the "KERNEL32!" part some kind of decoration, not really part of the symbol. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: How to set a breakpoint on imported Win32 function? 2020-01-17 7:46 ` Eli Zaretskii @ 2020-01-17 8:41 ` Ruslan Kabatsayev 0 siblings, 0 replies; 8+ messages in thread From: Ruslan Kabatsayev @ 2020-01-17 8:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Luis Machado, gdb On Fri, 17 Jan 2020 at 10:46, Eli Zaretskii <eliz@gnu.org> wrote: > > > From: Ruslan Kabatsayev <b7.10110111@gmail.com> > > Date: Thu, 16 Jan 2020 23:00:04 +0300 > > Cc: Luis Machado <luis.machado@linaro.org>, gdb@gnu.org > > > > > If I start a MinGW program under GDB, and then put a breakpoint on > > > ExitProcess, I get this: > > > > > > Temporary breakpoint 2, main (argc=2, argv=0xa42848) at emacs.c:934 > > > 934 bool no_loadup = false; > > > (gdb) break ExitProcess > > > Breakpoint 3 at 0x7c81bfa7 > > > (gdb) info breakpoints > > > Num Type Disp Enb Address What > > > 3 breakpoint keep y 0x7c81bfa7 <KERNEL32!ExitProcess+5> > > > > > > So it seems that GDB already knows how to put breakpoints on such > > > functions: you just need to name them without the DLL-name part. > > > However, I'm not sure I understand what is meant above by "functions > > > imported by name". How exactly were they imported? Does the above > > > technique work for you? > > > > They were imported as named functions usually are, i.e. not by > > ordinal. I just said this to emphasize that GDB should be able to find > > these symbols. > > Doesn't the fact that "break ExitProcess" works mean GDB _is_ able to > find the symbol? Maybe I'm missing something, but I always considered > the "KERNEL32!" part some kind of decoration, not really part of the > symbol. Well, the problem was that "break ExitProcess" failed to locate the symbol and suggested to wait for a shared library load, after which the breakpoint got missed, as if kernel32.dll hadn't been loaded. But unfortunately, now after I've tried to reproduce the problem on the original machine where I had it with the original app I debugged, I can't reproduce it. Must have been my own mistake. GDB successfully finds the symbols, and breakpoints trap as they should. Thanks anyway, and sorry for the noise. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-01-17 8:41 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-15 22:42 How to set a breakpoint on imported Win32 function? Ruslan Kabatsayev 2020-01-16 14:54 ` Luis Machado 2020-01-16 17:17 ` Ruslan Kabatsayev 2020-01-16 18:14 ` Luis Machado 2020-01-16 18:28 ` Eli Zaretskii 2020-01-16 20:01 ` Ruslan Kabatsayev 2020-01-17 7:46 ` Eli Zaretskii 2020-01-17 8:41 ` Ruslan Kabatsayev
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).