From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97071 invoked by alias); 16 Jan 2020 20:01:02 -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 97010 invoked by uid 89); 16 Jan 2020 20:01:00 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,SPF_SOFTFAIL autolearn=no version=3.3.1 spammy=HX-Spam-Relays-External:2607, HX-Spam-Relays-External:f8b0, H*RU:2607, H*RU:f8b0 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; Thu, 16 Jan 2020 20:00:49 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35028) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1isBJe-0003Ys-SB for gdb@sourceware.org; Thu, 16 Jan 2020 15:00:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50848) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1isBJc-0004Zi-DN for gdb@gnu.org; Thu, 16 Jan 2020 15:00:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1isBJY-0003Qj-3A for gdb@gnu.org; Thu, 16 Jan 2020 15:00:28 -0500 Received: from mail-io1-xd32.google.com ([2607:f8b0:4864:20::d32]:34612) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1isBJQ-0003Go-Vk; Thu, 16 Jan 2020 15:00:17 -0500 Received: by mail-io1-xd32.google.com with SMTP id z193so23337056iof.1; Thu, 16 Jan 2020 12:00:16 -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=18p3mCu2llopZUJ/rke+dU2JKgi+BKUdDO6JaXaEFJQ=; b=DTi9TUz6wMNKfP0nVJRZrdcYYZCcDQQz/Tqh17AEpYFtSKgJv3+9fZy+gk/UnYoyW5 eIin9ai3ueWf6E+KMVq6/cyMOOiqNaRj6A3CDREFcbCcOzs4IDLQfWmTSQEpB0A/zG/L ROPbDLDsKPUOj+yiRXIczIZtOMzNVYX1a5FbrY82Ypi9x8OZKld7ZtitgUcl3v8g0C87 4rdmd+8w9RVlP+Z2O14Xsj+lj85c6npvBz944erhM1xEUewsC/pCk4vWdy6tSy5ep6pJ uwRS6RpwFWdOCiolKAJXg/+gVfg65N4/tI0npYsBwkAa1HdUdBrxNYm5o5Sqfi0pAu6N 3VRw== MIME-Version: 1.0 References: <4d48b93e-6ae7-2f27-1b2e-9e06899bec6d@linaro.org> <98c5e02a-9310-268d-3a0f-abe71b2dd47f@linaro.org> <83o8v32r4a.fsf@gnu.org> In-Reply-To: <83o8v32r4a.fsf@gnu.org> From: Ruslan Kabatsayev Date: Thu, 16 Jan 2020 20:01: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::d32 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/msg00026.txt.bz2 On Thu, 16 Jan 2020 at 21:28, Eli Zaretskii wrote: > > > Cc: gdb@gnu.org, Eli Zaretskii > > From: Luis Machado > > 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 > > 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.