From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 28E993858C53; Thu, 3 Nov 2022 08:43:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 28E993858C53 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667465041; bh=7bhAIC99uuUpc7MIzN0Zy4rkitPAydO2Z+VZ8FK819U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=n24vBOb7VlWxm5vXKQn3F4eE++PJXy87ImwR8fs/OftKxec2+R04K5vEcCn/yRF+r D/CBmWvkO6DE1siZl6EYDcaVPpg2V//Ernvrf9wYvXr6nZIVqLNRDiZsMW/6Y3TI5s K/0K3HPIOE/K5nd6wsmJKjIb5dteZJBnAphr/tgY= From: "tomas.vanek at fbl dot cz" To: gdb-prs@sourceware.org Subject: [Bug tdep/29738] Arm M-profile dwarf2 unwinder performance suffers from exponential grows Date: Thu, 03 Nov 2022 08:43:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: tdep X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tomas.vanek at fbl dot cz X-Bugzilla-Status: WAITING X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: 13.1 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29738 tomas.vanek at fbl dot cz changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Arm v8 M-profile secure |Arm M-profile dwarf2 |extension dwarf2 unwinder |unwinder performance |performance |suffers from exponential | |grows --- Comment #4 from tomas.vanek at fbl dot cz --- (In reply to Luis Machado from comment #3) > I suppose we'd have the same issue with non-secure m-profiles, as they'd > need to do 3 ^ number_of_frame calls as well, based on this code: >=20 > else if (tdep->is_m) > { > CORE_ADDR sp > =3D get_frame_register_unsigned (this_frame, ARM_SP_REGNUM); > CORE_ADDR msp > =3D get_frame_register_unsigned (this_frame, > tdep->m_profile_msp_regnum); > CORE_ADDR psp > =3D get_frame_register_unsigned (this_frame, > tdep->m_profile_psp_regnum); Yes, the problem exists on all m-profiles. I edited the bug summary. As I wrote in the reply to Torbjorn email from 31th Oct (you should have received a CC, didn't you?), the exponential growth has the base "only" 2 f= or m-profile w/o the security extension, because ARM_SP_REGNUM is read from CF= A in dwarf2 cache and does not generate new get_frame_register_unsigned() reques= t. Unfortunately each exponential base greater than 1 is strong enough to spoil the performance. If the debugged app has 16 consecutive dwarf2 frames the '= bt' command is for very very patient users only. --=20 You are receiving this mail because: You are on the CC list for the bug.=