From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91755 invoked by alias); 9 Mar 2017 13:24:42 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 86919 invoked by uid 89); 9 Mar 2017 13:24:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-qk0-f179.google.com Received: from mail-qk0-f179.google.com (HELO mail-qk0-f179.google.com) (209.85.220.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 09 Mar 2017 13:24:31 +0000 Received: by mail-qk0-f179.google.com with SMTP id v125so115929117qkh.2 for ; Thu, 09 Mar 2017 05:24:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CWwCC9bXb6mP4GzoglKD2vYUmlDpWgKG9/avzDuUxMI=; b=MlnOB8FyKi/mYF86HF8V0+D3+TxI6n9aLbCWMubcmgCdDmkIx/D5z4mmDo8i/8vMbR NDpGoxJxIBi+SBx5uvkmttbwBnDEQ+T/NifNxYD0Srx+vFJHKGLvRjnfH3ukne5mlPRv 0GzrWCGdY05MOsGXE9W10ciFmbV2vcrJe8ZqJR5g3HteDR/wGtxcWrXqvx3DrXgcBMni fQkYKZEerBrCUXzED/UN/qn+s3Ef7ghi1NMxsN9NaaYGF+90uWj0u1U+RXToVr95gggv ZBQhVyx/yqnpVajc7kAxN6EZZZC2hWj9c7fLGodL+b6obNPG5lPuT1sC+GR3SB4SjKTn 0pEA== X-Gm-Message-State: AMke39khEbeN7r2uC3Md03201hj/AE/C5y5KR4AaSdF2M6utqegeJu8xpgR79moFQLimTH9lFRZND6OM4cTF3Q== X-Received: by 10.200.45.59 with SMTP id n56mr14178386qta.137.1489065870114; Thu, 09 Mar 2017 05:24:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.140.194 with HTTP; Thu, 9 Mar 2017 05:24:29 -0800 (PST) In-Reply-To: <1488916527.22552.8.camel@caviumnetworks.com> References: <1488837762.2866.268.camel@caviumnetworks.com> <867f41wfph.fsf@gmail.com> <1488916527.22552.8.camel@caviumnetworks.com> From: Yao Qi Date: Thu, 09 Mar 2017 13:24:00 -0000 Message-ID: Subject: Re: [Patch v2 1/2] Enable ILP32 mode in gdb on aarch64 To: Steve Ellcey Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00119.txt.bz2 On Tue, Mar 7, 2017 at 7:55 PM, Steve Ellcey w= rote: > I have been looking at the code and offsets used in aarch64_linux_sigfram= e_init > but I haven't had much luck in understanding the layout of the frames or = the > changes needed between the 32 and 64 bit ABIs. > > The code has these magic numbers: > /* These magic numbers need to reflect the layout of the kernel > defined struct rt_sigframe and ucontext. */ > #define AARCH64_SIGCONTEXT_REG_SIZE 8 > #define AARCH64_RT_SIGFRAME_UCONTEXT_OFFSET 128 > #define AARCH64_UCONTEXT_SIGCONTEXT_OFFSET 176 > #define AARCH64_SIGCONTEXT_XO_OFFSET 8 > > I think AARCH64_SIGCONTEXT_REG_SIZE is OK, registers are still 8 bytes lo= ng > in ILP32 mode. > > I am not sure what AARCH64_RT_SIGFRAME_UCONTEXT_OFFSET is supposed to > represent. Is it the size of the rt_sigframe structure? Or the > offset from rt_sigframe to the sigframe structure inside of rt_sigframe? > (i.e. the size of sigframe). I have the same problem with the other probably because they are magic, :) the comments above these macros are The handler then needs to recover the saved register set from ucontext.uc_mcontext. to your question, they are about offsets. That is how I get the offsets (I am not the author of this piece of code), load vmlinux into gdb, and examine the offsets, (gdb) ptype struct ucontext type =3D struct ucontext { unsigned long uc_flags; struct ucontext *uc_link; stack_t uc_stack; sigset_t uc_sigmask; __u8 __unused[120]; struct sigcontext uc_mcontext; } (gdb) p/d &((struct rt_sigframe *) 0)->uc $8 =3D 128 it is AARCH64_RT_SIGFRAME_UCONTEXT_OFFSET. (gdb) p/d &((struct rt_sigframe *) 0)->uc->uc_mcontext $9 =3D 304 it is AARCH64_RT_SIGFRAME_UCONTEXT_OFFSET + AARCH64_UCONTEXT_SIGCONTEXT_OFFSET, > magic numbers, I am just not sure what they represent. I am also not > sure if just changing the offset numbers is all that is needed or if > there is some copying that needs to be done to massage the ILP32 formats > into the expected layout. I have never done any kernel work and was not > around when the original aarch64 ILP32 work was done so I am not very > familiar with the history of all this. > Assuming ILP32 kernel patches is correct, you can get these magic number by loading ILP32 kernel vmlinux, and doing these steps I do above. --=20 Yao (=E9=BD=90=E5=B0=A7)