From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id PZM3E3Nk+2J13ycAWB0awg (envelope-from ) for ; Tue, 16 Aug 2022 05:33:39 -0400 Received: by simark.ca (Postfix, from userid 112) id 42AE21E5EA; Tue, 16 Aug 2022 05:33:39 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=L40wNBl6; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id EF69A1E13B for ; Tue, 16 Aug 2022 05:33:38 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 77AE4385828F for ; Tue, 16 Aug 2022 09:33:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 77AE4385828F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1660642418; bh=gKTonZ7YchvGLrg6uoGTrMukV/zowIZPFrcTD03gyT0=; h=Date:To:References:Subject:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=L40wNBl6ZzGT+mNXBZ6/ytCmn5+WwHxE/XIGNU1TKajFqYMWdT2F+/0AyPNRaVcDW AGYjXPbp8rxwN2wsIEmPaWb2IsfFZMr0C+lbPlsymCsox8B29WLba/hsu45iDMEAJX 8BB03nsjjMBIGIMzaxYthSNSnm4oRcJ24reG6dW8= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 6CDEB3858C20 for ; Tue, 16 Aug 2022 09:33:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6CDEB3858C20 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-83-dalnGsybNRW6c9dZgUaA_Q-1; Tue, 16 Aug 2022 05:33:08 -0400 X-MC-Unique: dalnGsybNRW6c9dZgUaA_Q-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7EBD180231E; Tue, 16 Aug 2022 09:33:08 +0000 (UTC) Received: from [10.33.36.178] (unknown [10.33.36.178]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0918918ECC; Tue, 16 Aug 2022 09:33:07 +0000 (UTC) Message-ID: <2271bb26-4534-44ce-b7e4-551343ffa871@redhat.com> Date: Tue, 16 Aug 2022 10:33:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 To: hilbert , Luis Machado References: <700833f8.5150.182a59bc271.Coremail.swdtian@163.com> <217b746f-65e8-66c0-1678-376eb8cb1aca@arm.com> <5c30085e.8da0.182a5f3377d.Coremail.swdtian@163.com> Subject: Re: How does GDB get the function call stack In-Reply-To: <5c30085e.8da0.182a5f3377d.Coremail.swdtian@163.com> X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Andrew Dinn via Gdb Reply-To: Andrew Dinn Cc: gdb@sourceware.org Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 16/08/2022 10:19, hilbert via Gdb wrote: > @Luis Machado > Thank you very much . > What does the sentence “functions without debug information”mean? Does it refer to the call stack information from the rpb register? > If there is no debug information, the call stack can be obtained. Why does gdb still need DWARF2 unwind information? When it says without debug information I believe that means without DWARF info. This info is located either in .debug_xxx sections embedded in the binary or, alternatively, supplied in a separate dwinfo/dwz file that is tied to the binary (e.g. by search path and file name or by a build id). DWARF .debug_frame info can specify a lot more than how to do a stack unwind. So, while the other methods enable this specific operation they do not enable many other useful actions that gdb might need to establish frame context and which DWARF info may enable. For full details see the DWARF standard(s). regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill