From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by sourceware.org (Postfix) with ESMTPS id B18EE3858413 for ; Fri, 6 May 2022 16:12:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B18EE3858413 Received: by mail-lf1-x12e.google.com with SMTP id h29so13402686lfj.2 for ; Fri, 06 May 2022 09:12:03 -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:cc; bh=lXm6tOLWAdQ3sk+IhB9QgsB33J3J3u2PPfDVbgfg44o=; b=B7H9xjUzlOswIFirFlsDU9kF3q3OmM1ChQHE+cjX/jpjWznNZpgBLyusoR2KNr6eHI InYGRuuKFaA3s98gwl/6aSPHTmb5O0RTOtFjLWCp49It1IS3oDUfCqTnlKfaxFmbCS3d e0z0wimKl6z94Qtb8Vw+irYrLeqUTCrR8BBCVVW9GQ95wY7jdRZfNDe66Cc+XC/GqS9D Htn2JM3RzY3ywkDN1O7YDHgmFksIF4nJxfWqw4VE+sUji6e5UB4B3v88Yg/xzN5s6wJo QeEYtrIjyPH+55tqF/zNUq6KY0Ct87/iPz8utdZgFSusr84H09ef5bqWIb8wfE0I0qzQ odkw== X-Gm-Message-State: AOAM533ZcR1Oao/AF3mmc92o43YgHUBG69KZlnuk+OwjFmtB2NxJYmjQ GqD5LTIa7SNNnas4YI1vSatQ1y+8omg1+6pI5T2g5rr7quExzw== X-Google-Smtp-Source: ABdhPJzQgV4RYq5r0wq5CcoKvPfS5BEr7iAdJUyDCB+eJVC704GjzpkMxaEttjfJJTPxKaLZ/JJWOO7Y4ka18M0buLI= X-Received: by 2002:a19:7605:0:b0:473:d5f0:3bd7 with SMTP id c5-20020a197605000000b00473d5f03bd7mr2933058lff.477.1651853522192; Fri, 06 May 2022 09:12:02 -0700 (PDT) MIME-Version: 1.0 References: <257aa215-a141-6d9b-672d-ea8ce209b107@arm.com> In-Reply-To: <257aa215-a141-6d9b-672d-ea8ce209b107@arm.com> From: Yichao Yu Date: Fri, 6 May 2022 12:11:50 -0400 Message-ID: Subject: Re: Restoring pc to a different value than lr on aarch64 To: Luis Machado Cc: gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.8 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 16:12:06 -0000 > > 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. > > > > Yes, GDB always assumes the PC from the previous frame is the LR from > the current frame. That is what GCC generates. > > If a different setup is needed, GDB needs to be taught about it. I agree the current code makes sense for what gcc generates. However, I think given the document from arm, explicitly setting the PC value in the unwind info should also work. Would a patch similar to the one above be acceptable to fix this issue? A related issue is that gdb also seems to be ignoring the return address register in CIE. There is at least one use of it in glibc[2] where the return address register is set to x15 instead. I've verified that gdb is currently unable to unwind after the call to `strlen` from `rawmemchr` even though the return address is still in x15. I thought this can be fixed by chaiming that PC is RA just like the fallback case but that is apparently not working... [2] https://github.com/bminor/glibc/blob/b92a49359f33a461db080a33940d73f47c756126/sysdeps/aarch64/rawmemchr.S#L34 > >> > >> 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. > > This seems to work in a similar way as signal handler. GDB needs to be > taught where to find the registers so it can properly unwind things. > > >> > >> [1] https://github.com/ARM-software/abi-aa/blob/8a7b266879c60ca1c76e94ebb279b2dac60ed6a5/aadwarf64/aadwarf64.rst#note-9 >