From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by sourceware.org (Postfix) with ESMTPS id B98573952491 for ; Fri, 6 May 2022 12:06:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B98573952491 Received: by mail-lf1-x12c.google.com with SMTP id bq30so12229016lfb.3 for ; Fri, 06 May 2022 05:06:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gnGWep3vVWPW4RZpDOeSyc8HuYT09H2Qm9TZpkeSrZ4=; b=rWCxzBfZCRAK1hIQsSNNyFqHPLuTuqsVZBHKf7oiREQFpWpKrEDcvXTz385y71dPhM zIykDmbxeJKV8sz4onRdqbov5x0k88M7Txi7grkYsVNVTYgioLtf8KD3soD7HhsPaS32 CIIUGuo1baNTxGVUDYNWy+PHlOlvGfJlDdA+kJeDKqCMAk5mXIyKl9XYoLdbkPiWB2Fj e+4Pj+Vw8OS/yg8cmk0nFxheLDECDogeq2VCGBXVvfySGjPpRbAL/ogLOtlgmrpeo7Hv LS4uztm5eO8eIIrdCZS4OvxO3fHnSzSL3dmUsjJKWVQObF/ZZe6HpOVaeTs3UKJGo8LT N7UQ== X-Gm-Message-State: AOAM533Qj8EhQUavWwbPP5IR717SScqqYX7GLQcM4+DqF3meCRLE02PK 29Dznn+kAs0ymZxdwX6ONyjbqd1heM1uYRaLfpk5xdwE2IH+PQ== X-Google-Smtp-Source: ABdhPJwJfXaOKpnZK10fzAy0If89l7UkIA5jh36ga+VZ/T8CXsdaqsTCqloSVlzXbeEq+KqzZbkdjUI5tpfut+t/Gwo= X-Received: by 2002:a19:6b19:0:b0:471:f39c:7d1d with SMTP id d25-20020a196b19000000b00471f39c7d1dmr2329115lfa.443.1651838766460; Fri, 06 May 2022 05:06:06 -0700 (PDT) MIME-Version: 1.0 From: Yichao Yu Date: Fri, 6 May 2022 08:05:55 -0400 Message-ID: Subject: Restoring pc to a different value than lr on aarch64 To: gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 06 May 2022 12:06:11 -0000 I have a case in my code where I want to restore the value of lr (x30) during unwinding, to a different value than the return address of the code. However, it seems that for aarch64, (aarch64_dwarf2_frame_init_reg among other functions) hardcode x30 and pc to be exactly the same value after unwinding. According to aadwarf64[1], > having both LR and PC columns is useful for describing asynchronously created stack frames. A DWARF expression may use this register to restore the context in case of a signal context. so assume the intention is that if I explicitly unwind the pc in addition to lr, it should work. I tried to do that, and also to set return address column to 32, as well as trying to mark the frame as signal frame but none of them seems to work. Is there any way for gdb to honer the explicit unwinding of pc? Also it seems that the sp is also card coded to be cfa. My code also contains explicit saving and restoring of that as well so if that's the case (haven't tested yet) it would be a problem too... Would it be possible to not use this hard-coded logic if the frame contains explicit override of the pc value? Yichao A bit more about the actual code. This is done as part of runtime patching code. The actual restoration of lr is done by returning to a runtime allocated stub that restores lr and directly branch back to the return location. After returning, all registers values are restored back to their previous one. The stack pointer is also switched out since we cannot rely on how much stack space the call site has available. [1] https://github.com/ARM-software/abi-aa/blob/8a7b266879c60ca1c76e94ebb279b2dac60ed6a5/aadwarf64/aadwarf64.rst#note-9