From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126272 invoked by alias); 24 Aug 2019 10:27:23 -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 126083 invoked by uid 89); 24 Aug 2019 10:27:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=pc, came, UD:name, HTo:U*gdb X-HELO: mail-io1-f65.google.com Received: from mail-io1-f65.google.com (HELO mail-io1-f65.google.com) (209.85.166.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 24 Aug 2019 10:27:21 +0000 Received: by mail-io1-f65.google.com with SMTP id t3so25943802ioj.12 for ; Sat, 24 Aug 2019 03:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=EAxrAKOzWByBG0I8UM4AZ7Kpc1qNRFWBFbyJNTGue8c=; b=pPMuLeNQcYqjwtpk1GsO7ZMg9HaQqPClNTXzd6+N8Yz76KP1w+oiIBG9i+XatFCQlW BRxNtTohbX3JDRk6A4nhuB10gdK+J4sMk1upcAy3Ese8WeEOXzzYhaTqhLotKEuroQLO uMI82xtiLV0CR6kIMmqRAu7/hia7ziDi//ZUcB6dG7S4QgdFE51ok0j9X11jB/odogVU 13dqRFDLBk6u0oIQCvHzTUeGESfDP0bVgkjx+mFLbnZ072jEz9Xz7hI+TN3juLZ/2Xrq /XDAN2h09IFGty2B720ftt4XlD+cP8wVzl1wswslXDpHI0L6LVNhOstE8y7t/J11DoMi X5Gw== MIME-Version: 1.0 From: Andrea Cardaci Date: Sat, 24 Aug 2019 10:27:00 -0000 Message-ID: Subject: Function address incoherence To: gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-08/txt/msg00035.txt.bz2 Hi, I could use some clarification about the following behavior that initially came up in a issue [1] opened to the gdb-dashboard project. Basically in some cases it appears that there's some kind of symbol conflict (this is a bad name but I don't know how to else call it). I can only reproduce it on a 32 bit Linux machine with the following: vagrant@ubuntu-xenial:~$ gcc -x c -o test - <<<'int main(){}' vagrant@ubuntu-xenial:~$ gdb -q --batch test -ex 'b *0' -ex r -ex disassemble -ex 'p &_start' Breakpoint 1 at 0x0 Warning: Cannot insert breakpoint 1. Cannot access memory at address 0x0 Dump of assembler code for function _start: => 0xb7fdba20 <+0>: mov %esp,%eax 0xb7fdba22 <+2>: call 0xb7fdc5c0 <_dl_start> End of assembler dump. $1 = ( *) 0x80482e0 <_start> As you can see, $pc points to 0xb7fdba20 and the disassemble commands reports that it is part of _start, yet if I print the address of _start I obtain a different value (0x80482e0). (Using the disassemble command is just an example, simply printing $pc shows 0xb7fdba20 <_start>.) Now the latter (0x80482e0) is what appears to be the *real* _start: vagrant@ubuntu-xenial:~$ readelf -s test | grep ' _start' 60: 080482e0 0 FUNC GLOBAL DEFAULT 14 _start While the other address (0xb7fdba20) appears to be contained in /lib/ld-linux.so.2: 0xb7fdb860 - 0xb7ff48fd is .text in /lib/ld-linux.so.2 According to objdump -d /lib/ld-linux.so.2, $pc points at the following instructions in the _dl_rtld_di_serinfo function: 00000860 <_dl_rtld_di_serinfo@@GLIBC_PRIVATE-0x83c0>: [...] a20: 89 e0 mov %esp,%eax a22: e8 99 0b 00 00 call 15c0 So where does the _start reported by the disassemble command comes from? Is this a GDB bug or I'm missing something here? Back to the gdb-dashboard issue, I fetch the function address with gdb.parse_and_eval(frame.name()).address and since frame.name() is _start, the address that I obtain is 0x80482e0 instead of 0xb7fdba20 thus I end up displaying wrong offsets. Best, Andrea [1]: https://github.com/cyrus-and/gdb-dashboard/issues/70