Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Ruslan Kabatsayev <b7.10110111@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Luis Machado <luis.machado@linaro.org>, gdb@gnu.org
Subject: Re: How to set a breakpoint on imported Win32 function?
Date: Fri, 17 Jan 2020 08:41:00 -0000	[thread overview]
Message-ID: <CAHEcG95i9v0FV0TroM2i5GtF+q+g4SBT6M+Qt2C61f=h0VcsRw@mail.gmail.com> (raw)
In-Reply-To: <83imla34qm.fsf@gnu.org>

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.


      reply	other threads:[~2020-01-17  8:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15 22:42 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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHEcG95i9v0FV0TroM2i5GtF+q+g4SBT6M+Qt2C61f=h0VcsRw@mail.gmail.com' \
    --to=b7.10110111@gmail.com \
    --cc=eliz@gnu.org \
    --cc=gdb@gnu.org \
    --cc=luis.machado@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox