From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126512 invoked by alias); 13 Mar 2019 14:25:10 -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 126501 invoked by uid 89); 13 Mar 2019 14:25:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=1.7 required=5.0 tests=BAYES_50,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,SPF_SOFTFAIL autolearn=no version=3.3.1 spammy=H*r:TLS1.0, HX-Spam-Relays-External:4864, H*r:f8b0, HX-Spam-Relays-External: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; Wed, 13 Mar 2019 14:25:07 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47138) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h44ob-0003mH-Uq for gdb@sourceware.org; Wed, 13 Mar 2019 10:25:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39355) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h44oa-00044w-CN for gdb@gnu.org; Wed, 13 Mar 2019 10:25:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h44oZ-0003lD-HP for gdb@gnu.org; Wed, 13 Mar 2019 10:25:04 -0400 Received: from mail-io1-xd31.google.com ([2607:f8b0:4864:20::d31]:44033) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h44oZ-0003jq-8g for gdb@gnu.org; Wed, 13 Mar 2019 10:25:03 -0400 Received: by mail-io1-xd31.google.com with SMTP id u12so1808930iop.11 for ; Wed, 13 Mar 2019 07:25:00 -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=8sWTxweRv7mN/IlwSoDd7GhJzpOJTGlEhDPwFjGEinU=; b=eUB1/QtvywRZSv+VeKp4gZh9/JFg0OMTghpAdOZ1caLdLGE3/Iohc18rFiVLCOkmQO NAI8p7e9Pin291sf6xjrCoqyUIhRGXVaEjxGtz9ynGeygkrkT2QtqCjcoBe8oLaDBDhp kXE0lzWUqp6vCWrHvqrGZWGiQtIAw4JRN0i2lC/7bjzJy9B3PgEERkM5PUGIJ/fxlnWg dQhTSrDtdUxlWZ3P4cCpk2YwqKvBGYTDm+qlpVmWgta/TayMsqKaKfO2D96josiPmbxO LPuAoy0lpNqcP/QiMwFn1vyWEqxKFAH55ULWZbB35D2qVNog5hcip/w0OqbChUnvUnt5 lnKQ== MIME-Version: 1.0 From: =?UTF-8?Q?Jirka_Koutn=C3=BD?= Date: Wed, 13 Mar 2019 14:25:00 -0000 Message-ID: Subject: question about why gdb needs executable's binary To: gdb@gnu.org X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d31 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-03/txt/msg00023.txt.bz2 Hello, If we assume debugging a core file generated by an excutable with stripped symbols (that gdb is able to find and load correctly in my case), I was wondering why does gdb still need the executable's binary as well? Is there some additional information retrieved from the executable? It does seem the stack trace does not get resolved if the executable file is not specified, but if I understand it right, PT_NOTE contains address ranges and shared libraries names as well, so the information to build the strack trace is there already. So say if I only start gdb and then core-file , why does 'where' return a list of question marks? What is the missing bit of information there? I'm not questioning correctness or anything, if it's like that from historical reasons I'm cool with that, I'm just trying to understand the thing. Thank you, Jirka