From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129772 invoked by alias); 17 Jan 2020 08:41:30 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 129764 invoked by uid 89); 17 Jan 2020 08:41:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=BAYES_05,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,SPF_SOFTFAIL autolearn=no version=3.3.1 spammy=HX-Spam-Relays-External:2607, H*RU:f8b0, HX-Spam-Relays-External:f8b0, H*RU:2607 X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Jan 2020 08:41:20 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44128) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1isNBu-0004qZ-RQ for gdb@sourceware.org; Fri, 17 Jan 2020 03:41:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40364) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1isNBu-0002Wv-FK for gdb@gnu.org; Fri, 17 Jan 2020 03:41:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1isNBt-0004pn-C7 for gdb@gnu.org; Fri, 17 Jan 2020 03:41:18 -0500 Received: from mail-il1-x12d.google.com ([2607:f8b0:4864:20::12d]:34563) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1isNBq-0004oA-WD; Fri, 17 Jan 2020 03:41:15 -0500 Received: by mail-il1-x12d.google.com with SMTP id s15so20697576iln.1; Fri, 17 Jan 2020 00:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wezC5RmANSSKhaWJA7wIYUGVEBa4+erFLyjufGc122E=; b=Orps06i+/dkwuQnK4j3uYoRcVEAwu7DrQxF39b8ZSjKPYpBwflL25wODvIoRhKM7/5 sh4m3VwGYTjiRC2xRrZQ+hkPDqJwjHSKCOSsONUKjY6WNYgxC8KeN826+LhG82zFo+QX OcAuBE8/SIl+Uy041IJW1rV+iL8zyUdwrGb3V05SWWneVFJVeIL4+beArdnakWVVEik6 V0AvNV3IPywBlovxSqGUz5MMk57C3Jm7rkQbxkxpMhdS1TzaPE0tZZ8sW0dtD8qggK56 c+kQH0iYgQkU/2pRQLDKa1tYS3yZXSsArPEihfpRx/BBVnc0t238rCDOyZ8sNhvLqVSq BqwA== MIME-Version: 1.0 References: <4d48b93e-6ae7-2f27-1b2e-9e06899bec6d@linaro.org> <98c5e02a-9310-268d-3a0f-abe71b2dd47f@linaro.org> <83o8v32r4a.fsf@gnu.org> <83imla34qm.fsf@gnu.org> In-Reply-To: <83imla34qm.fsf@gnu.org> From: Ruslan Kabatsayev Date: Fri, 17 Jan 2020 08:41:00 -0000 Message-ID: Subject: Re: How to set a breakpoint on imported Win32 function? To: Eli Zaretskii Cc: Luis Machado , gdb@gnu.org Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::12d X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00030.txt.bz2 On Fri, 17 Jan 2020 at 10:46, Eli Zaretskii wrote: > > > From: Ruslan Kabatsayev > > Date: Thu, 16 Jan 2020 23:00:04 +0300 > > Cc: Luis Machado , 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 > > > > > > 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.