From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8E2593858425; Fri, 4 Nov 2022 11:04:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8E2593858425 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667559871; bh=3fZMqlHkVi0BS5+Q1MrssCKwjGG2y9+eh3i3ikQLUY4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pWpP4bMK9Qq8+3BHikthv5rZBWl6fHwGgpd7HQZWt9jUxMgLPyvJscfkqsPnSGwTg R5AlKQaETWklZ5eV1V5Q8lkWsJ3/E2cctSxQhsb6Fz3+NaTdK3etQpdBbxY9Xq3TAN c+OrJ0v7Ov0qDaaMns0jTBhk7+vRPtK/okw4pZvs= 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 growth Date: Fri, 04 Nov 2022 11:04:29 +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: 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 --- Comment #5 from tomas.vanek at fbl dot cz --- (In reply to Luis Machado from comment #1) > My understanding is that there is only one active SP at any point, ... >=20 > We should probably have code to figure out what is the expected stack > pointer register before we go about fetching values. That should bring the > number of requests down. Does that sound reasonable? Let's have M-profile without sec ext. To figure out the active stack pointer we need xPSR and CONTROL registers. So we need to fetch 2 registers and the 3rd fetch will get the active stack pointer. Provided that fetching xPSR and CONTROL does not generate addition= al requests we need approx n^2 + 2n calls get_frame_register_unsigned() where = n is frame level. It's much better than exponential but not a great performance.= .. And the code would be kind of balancing on the edge: if somebody adds fetch= ing one more register we get into an exponential again. Why not use a cache to ensure linear dependency to the frame level? The prologue cache is occupied by dwarf2 unwinder. We need small changes in dwarf2/frame.c code to allow arm_dwarf2_prev_register() to allocate struct arm_prologue_cache and store the this_cache pointer to struct dwarf2_frame_cache as a secondary, cascaded cache. This would allow re-using the stack pointer related code in arm_make_prologue_cache(), arm_cache_switch_prev_sp() and arm_cache_set_active_sp_value() Or alternatively modify dwarf2/frame.c to allow changing struct dwarf2_frame_state_reg on the fly from arm_dwarf2_prev_register(). arm_dwarf2_frame_init_reg() initializes reg->how =3D DWARF2_FRAME_REG_FN; reg->loc.fn =3D arm_dwarf2_prev_register; The first arm_dwarf2_prev_register() call makes the decision which sp is ac= tive and sets reg->how =3D DWARF2_FRAME_REG_CFA; for the active sp and reg->how =3D DWARF2_FRAME_REG_SAME_VALUE; for an inactive sp. All following get_frame_register_unsigned() will reuse the decision cached = in reg->how and fetch the selected register directly. What do you thing? --=20 You are receiving this mail because: You are on the CC list for the bug.=