From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id 59E8C3856DC3 for ; Wed, 12 Oct 2022 03:32:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 59E8C3856DC3 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x231.google.com with SMTP id h8so7140511lja.11 for ; Tue, 11 Oct 2022 20:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=c8XwYfxt7DEGg1Sfit42PHZps/dPC1wKb26SS0rfybM=; b=L4nsOxsI/7curbvGEONkUkG4Lw2ceLe0Gz/8OU0VIily09zhIi7N6qenHnQSv/yHC/ ZZA2aak4Hdt+Yl0MVBHYxtWo30Z35PXu+5WeaLn80jWFjhQgLxFvTlG6hgMTstblBEOd wgfUPp0+NyUe3+7qei99sJEP73N5MuGmH7gwmEUeUrcFp/VxtCbodehSj3KiSpbczfCH 7rFLAuGp2AbAqKYSF4S0GfwWKCrX5PhpmC70KShnhqq9Mm/Jf6LTLVX2aQc7WTpUpMDC Qloykyd4NNW5pPBvFf4LZSMoDiqdCDye82O8TZN6RD1pI1jzu9ZToPq2emW53c/cwgEu 1q+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=c8XwYfxt7DEGg1Sfit42PHZps/dPC1wKb26SS0rfybM=; b=cwgElM6F1+rJs6o/YSnuA1nMgvbWi+tM2e2cAkIAUWpo83PgNSH/NSvrrK4qVCGjkT d60t/591w+a9r6skqKaFOB3gcQshCAqAyBfIZjiVRl1eepRA4xzTS1dONohW7FeDLrNn /dKM/edqBct+Xoj40NT1GNRX8Wcx5vN0IXuELJejRsC/+89h2BmtmyYE2vlXe9O3JUgj woInT/X4pjKVgZ0TDUz3FuhX+PMRWImliUHWWWlGjXTBVuRsZT8vMDAvKA16Lq4QweSu zKNgsYe6s9wo1iOfSyOgejxhGzBkYnofRHsLgfHOUT9ZuYRfCaBgChTimBjYhG5Obop5 YLAw== X-Gm-Message-State: ACrzQf3jj+UsEA87oQ2mT4aOg1SZNlmWoUuk6iabHydcAXVdVHosRkEu LC1m4Zxd/htj74kfQd43pHXk1KacTiLIPpu6U+9gaKuMmrKhug== X-Google-Smtp-Source: AMsMyM5M7yDQUIVJ3nmok7pxrMlXhhQ+Yd9RK7qwLeUGHvcm+duuy16HH5LxYJ6YR42nfi9ljfI79UxQ69bj3VaVW7E= X-Received: by 2002:a2e:a448:0:b0:262:f7c4:31ad with SMTP id v8-20020a2ea448000000b00262f7c431admr9958638ljn.283.1665545519237; Tue, 11 Oct 2022 20:31:59 -0700 (PDT) MIME-Version: 1.0 From: Gulshan Singh Date: Tue, 11 Oct 2022 20:31:46 -0700 Message-ID: Subject: Expected behavior of gdb.lookup_symbol() To: gdb@sourceware.org Content-Type: multipart/alternative; boundary="000000000000080e6505eace0965" X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000080e6505eace0965 Content-Type: text/plain; charset="UTF-8" Hi, I've noticed that the `gdb.lookup_symbol()` function in the Python API returns None for certain types of symbols. For example: $ gdb -q -nx -ex 'catch load libc' -ex 'run' /bin/ls Reading symbols from /bin/ls... (No debugging symbols found in /bin/ls) Catchpoint 1 (load) Starting program: /usr/bin/ls [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Catchpoint 1 Inferior loaded /lib/x86_64-linux-gnu/libselinux.so.1 /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libpcre2-8.so.0 __GI__dl_debug_state () at ./elf/dl-debug.c:116 116 ./elf/dl-debug.c: No such file or directory. (gdb) p __libc_malloc $1 = {void *(size_t)} 0x7ffff7df3120 <__GI___libc_malloc> (gdb) pi gdb.lookup_symbol('__libc_malloc') (None, False) (gdb) pi gdb.lookup_symbol('__GI___libc_malloc') (, False) Here I was expecting both calls to `gdb.lookup_symbol()` to return a `gdb.Symbol` object. I have debugging symbols installed. I determined the name of the file containing the debug symbols like this: (gdb) pi gdb.lookup_symbol('__GI___libc_malloc')[0].symtab.objfile And I looked for those symbols in that file like this: $ readelf -a /usr/lib/debug/.build-id/69/389d485a9793dbe873f0ea2c93e02efaa9aa3d.debug | grep __libc_malloc 5933: 00000000000a5120 828 FUNC LOCAL DEFAULT 15 __GI___libc_malloc 9639: 00000000000a5120 828 FUNC GLOBAL DEFAULT 15 __libc_malloc It seems that the only difference is one is a local binding and one is a global binding. Is this expected behavior? If so, why? And is there another way to get the address of a symbol like this, or should I just resort to calling `info address` with `gdb.execute()`? My GDB version is GNU gdb (Ubuntu 12.0.90-0ubuntu1) 12.0.90, and I'm on Ubuntu 22.04.1 LTS. --000000000000080e6505eace0965--