From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by sourceware.org (Postfix) with ESMTPS id 058223952491 for ; Fri, 6 May 2022 12:46:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 058223952491 Received: by mail-lj1-x233.google.com with SMTP id q130so9128646ljb.5 for ; Fri, 06 May 2022 05:46:45 -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:references:in-reply-to:from:date :message-id:subject:to; bh=fF9+bYyIxSDVhSyotXbNsbm/9HC0YhNbQHGq8KnwJuo=; b=vaRmFPaKpbQkzj5GshezjAA/0HN7KSQJmSu1RH6blixerPiYfFoKvdXm1dzx9wnD2p jsx7hGNxG9HdKSXF1QqueIogCiDj13PDHQk7gzyBxOvgEMtgtaLZTmD3rJ1Uq4yDAVCQ 0Ob8tmkb3QgFZaH+cgl91DTyGWS4uKAPQkv/k7+Y1O4ALDTcXv+TQQWH5CXKbe0YxDAo 5uH1Fg8wKcEFEF4f0MiebO1d9EgPmfQmttIGAFcjAmsFLHLXnnpZDd4So2aHJBrh/Q+L P17ojCkIRXjLeLBFZx7BUG0MJGzqcl7nMNRWnif4Lbu13q2s2kOFjC5OOIRCzCyvGZOi /VdQ== X-Gm-Message-State: AOAM531Db37NYvMzlmd/9RmR3JI4GpSISEF8iCGievCV04pa9ZySMzMz rbAgAqwJsYBCk+t8PcsVD5BsUAfjXmUArku4WwwzV1wMK+s3pw== X-Google-Smtp-Source: ABdhPJw9meBd+LYenZ0qEu7IKuCO1PRs0icJwUdgVR4necB66VeIrseUhSyYJ8WFOmHkS9IY52HN2bH5ju8nlQYxIv4= X-Received: by 2002:a2e:9812:0:b0:24f:2ccd:6f0f with SMTP id a18-20020a2e9812000000b0024f2ccd6f0fmr1942575ljj.395.1651841204053; Fri, 06 May 2022 05:46:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yichao Yu Date: Fri, 6 May 2022 08:46:32 -0400 Message-ID: Subject: Re: 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:46:48 -0000 On Fri, May 6, 2022 at 8:05 AM Yichao Yu wrote: > > 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. Actually I misspoke for that. It seems that sp is probably fine and the only thing missing causing pc to not work is that aarch64_dwarf_reg_to_regnum doesn't understand the PC dwarf reg number. It seems that the only thing needed is to add a + if (reg == AARCH64_DWARF_PC) + return AARCH64_PC_REGNUM; to that function. > > 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