From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id 492FE386F447 for ; Wed, 24 Jun 2020 15:06:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 492FE386F447 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wm1-x32d.google.com with SMTP id t194so2854340wmt.4 for ; Wed, 24 Jun 2020 08:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=+M3OPGdUhWp78qP6/I+Cqjemhu/mbS3o4EsOMY9WPUM=; b=G7bTIbLKvvvbYmO2AcXYYb8Hwjm46q/QUaJrTXr6yslwJAgNVhSB4qSiqI62pikeof xaa5uSMpQTJBfS0MqLc0jrqWVbivnkbIABsoJ8NoeeK0Fn3yZ3vmzaxNhxawIQqQTzFP 825bncqInZKESqFslDrFhjlrqn7bmefZM46VQDhulNEQCynpivNmrGqT/8RIyYMy21UD ZoDz1AQFTSIUqsZCxdviQ26HQ9LO+boyA1LAoRGaDeulkh/+HRoaq5ynjAbYQM+Hn+sI LvjVBK+/H4R2kgJZKeUxp4OTjuVV+CroNKsAJYB/nC8VKv3LBzUDdjbwTITn11W4yE15 6yrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=+M3OPGdUhWp78qP6/I+Cqjemhu/mbS3o4EsOMY9WPUM=; b=nYp973lhXfz33nTzjtjPJnarvmYQUrWLPuYSVJ43y07rIQ04Vq/mH/ASl6fOmXLkRO tObaywXsNMFbHViZ6ARawlvU/dHYv/liRnS4ddSGujP5zYf4LCEDN/uxWWUeba7PmiL5 dIw24UzQTKEvV0mmDYbqGqyqPJV5xOuE4day5E8Plz0I82OnCOzPEgYpzla0r8Z7KQqv LL2eztLqH8JyxE55Ji9V4Z1IWGxDvtWzXlMf6vrFOmtK0LweRsN7SKwSIOrCrdfZAtlb Rnxuyusjn0CDcn8MTJ8SfB64DwQknV/dP+vJfOJxrCje9x2PK5BhxoefaGgwfLAiw0Ai X9sQ== X-Gm-Message-State: AOAM531VMlU/6T59fT1oQ1dqGlkde4H8edxkYCfLamwRAUUr5Zec3cqj tu6VWEbt5yGRBzi+Zc9AF7qB6A== X-Google-Smtp-Source: ABdhPJw1oMwrrT+tPyHwPJPYDumtPh69Ywgu/AL0UT51qGnsrHJiDswgfjE6ryMUqx50Yrk9ed4X+g== X-Received: by 2002:a1c:3bc2:: with SMTP id i185mr30979639wma.33.1593011164321; Wed, 24 Jun 2020 08:06:04 -0700 (PDT) Received: from localhost (host86-128-12-16.range86-128.btcentralplus.com. [86.128.12.16]) by smtp.gmail.com with ESMTPSA id o29sm19797139wra.5.2020.06.24.08.06.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2020 08:06:03 -0700 (PDT) Date: Wed, 24 Jun 2020 16:06:02 +0100 From: Andrew Burgess To: Ahmad Nouralizadeh Cc: Jan Kratochvil , "gdb@sourceware.org" Subject: Re: GDB Frame Unwinding for Pure Assembly Code Message-ID: <20200624150602.GN623665@embecosm.com> References: <20200622213956.GA3486027@host1.jankratochvil.net> <20200623072654.GA3548953@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux/5.6.15-200.fc31.x86_64 (x86_64) X-Uptime: 15:57:07 up 16 days, 5:04, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Wed, 24 Jun 2020 15:06:07 -0000 * Ahmad Nouralizadeh via Gdb [2020-06-23 16:18:42 +0430]: > Thanks for the answer! Could you tell me why is an inline unwinder used? What you saw in your GDB backtrace was this: #5 0x00005555558b1b0b in frame_unwind_pc (this_frame=0x55555673c2e0) at frame.c:885 #6 0x00005555558b4f72 in _Z12get_frame_pcP10frame_info (frame=0x55555673c490) at frame.c:2379 #7 0x00005555558b50ea in _Z26get_frame_address_in_blockP10frame_info (this_frame=0x55555673c490) at frame.c:2410 #8 0x0000555555905d53 in inline_frame_sniffer (self=0x555556193520 , this_frame=0x55555673c490, this_cache=0x55555673c4a8) at inline-frame.c:215 #9 0x00005555558b719a in frame_unwind_try_unwinder (this_frame=0x55555673c490, this_cache=0x55555673c4a8, unwinder=0x555556193520 ) at frame-unwind.c:106 So GDB hasn't decided for sure that a frame is an inline frame, instead it is running the inline_frame_sniffer to see if a particular frame is an inline frame or not. In order to figure this out GDB needs to know the value of $pc in the frame that is being sniffed. To get the $pc value GDB asks the next frame (that would be a frame with a lower frame number in GDB terms) to unwind the $pc register. You can see this happening between frames #8 and #6 in the above, before finally in #5 we ask the next frame to unwind the $pc. Almost every frame will have had the inline frame unwinder run on it in order to figure out if it was an inline frame, that doesn't mean the inline frame unwinder will claim the frame. Hope that helps, Thanks, Andrew > > On Tuesday, 23 June 2020, Jan Kratochvil wrote: > > > On Mon, 22 Jun 2020 23:55:30 +0200, Ahmad Nouralizadeh via Gdb wrote: > > > But knowing the GDB mechanism to get over the problem will be helpful. > > > > GDB disassembles the code and tries to guess how to unwind it. > > amd64-tdep.c amd64_analyze_prologue(), amd64_frame_cache_1() etc. > > > > That is just a last resort way of unwinding (=a bug in the debuggee), there > > should always be .eh_frame in the debuggee, also for throwing exceptions > > across such .eh_frame-less functions if there is any callback there. > > > > > > Jan > > > >