From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 767703858D1E for ; Thu, 18 Aug 2022 14:05:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 767703858D1E Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-198-XRSpWOmVPFKkFRfw8NQogQ-1; Thu, 18 Aug 2022 10:05:19 -0400 X-MC-Unique: XRSpWOmVPFKkFRfw8NQogQ-1 Received: by mail-wm1-f69.google.com with SMTP id c66-20020a1c3545000000b003a5f6dd6a25so2753828wma.1 for ; Thu, 18 Aug 2022 07:05:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc; bh=tL1Mhn477uQ92A93u/7jftYOQ5FSfEcW0jLio+AdfKQ=; b=u0RRUw6zeLHy+7AWUUS5l4Hx/zkud/5gppbF6jzjZ5pqHVBA/IbgrNc8aG0LBgROiU h91Yz7B3KmP3lqFtzpDs4AyE9OJHhKywBNV2wRfeJAlSrTZZ19YQqj4SvXHU5cRjORuT c93NjjE5ImNTga6wBxbm783hILVIVZKpHwSsXpQSBgOCnxDxKVEgw+14pRK86y63KgHZ GrS9G7EpBpwgtafbTDJZN4ibQBcPNh2Z5uDEkUDq5H6eP55Li7KxFZs6sgvks/73KeYi X5f73lPMeDbwee29h7zIRRxjOaMPpvk5OUShg35ZCFhtDtKkDhKBybfvAGzpjyOYWxYf /PUQ== X-Gm-Message-State: ACgBeo2F1ddLct6BcTOdrnatobPumqD0nC3s7zdwJ7SjipcxQD4XTEoK kByJtmxJlYxXroo+fbSjJ9yO+FEsagyiG77oLctjuje5oNOf4jNx9tg/lD7sEHPR1VYlVUsFwZd GRTR04kUHeIY= X-Received: by 2002:a05:600c:a199:b0:3a5:dddf:ac6d with SMTP id id25-20020a05600ca19900b003a5dddfac6dmr1995475wmb.44.1660831517997; Thu, 18 Aug 2022 07:05:17 -0700 (PDT) X-Google-Smtp-Source: AA6agR5hJBmbtYLZoeIaeeksqNKnXLaSzQowJre9LbKVoaOyC77GHK76Bd4HdJ6Q9ORnfrWawGa4qg== X-Received: by 2002:a05:600c:a199:b0:3a5:dddf:ac6d with SMTP id id25-20020a05600ca19900b003a5dddfac6dmr1995459wmb.44.1660831517782; Thu, 18 Aug 2022 07:05:17 -0700 (PDT) Received: from localhost ([31.111.84.229]) by smtp.gmail.com with ESMTPSA id i3-20020a05600c050300b003a60edc3a44sm2523280wmc.5.2022.08.18.07.05.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Aug 2022 07:05:17 -0700 (PDT) From: Andrew Burgess To: Luis Machado , hilbert , gdb@sourceware.org Subject: Re: How does GDB get the function call stack In-Reply-To: <217b746f-65e8-66c0-1678-376eb8cb1aca@arm.com> References: <700833f8.5150.182a59bc271.Coremail.swdtian@163.com> <217b746f-65e8-66c0-1678-376eb8cb1aca@arm.com> Date: Thu, 18 Aug 2022 15:05:16 +0100 Message-ID: <87r11dabqb.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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: , X-List-Received-Date: Thu, 18 Aug 2022 14:05:22 -0000 Luis Machado via Gdb writes: > On 8/16/22 08:43, hilbert via Gdb wrote: >> Hi , >> There are 4 ways to get the function call stack in the GDB Internals Manual. https://sourceware.org/gdb/papers/unwind.html >> For x86_64, does GDB get information by parsing the .eh_frame section? Or just get the call stack by Parse the function prologues. >> >> >> > > I'd say mostly 1 and 2. 1 is usually used with functions without debug > information. 2 is used when there is debug information. To expand on this a little, at least for version of GCC I'm using on x86-64, the .eh_frame data replaces the .debug_frame data, so #2 and #3 are effectively merged. The two "issues" raised against .eh_frame don't make sense to me. As I understand it the .eh_frame encoding is roughly the same as the .debug_frame encoding, so I don't think there's much space saving, and GDB reads the .eh_frame information from the ELF, so the read-only concern seems like a non-issue. Thanks, Andrew