Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Steve Ellcey <sellcey@caviumnetworks.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [Patch v2 1/2] Enable ILP32 mode in gdb on aarch64
Date: Tue, 07 Mar 2017 19:55:00 -0000	[thread overview]
Message-ID: <1488916527.22552.8.camel@caviumnetworks.com> (raw)
In-Reply-To: <867f41wfph.fsf@gmail.com>

On Tue, 2017-03-07 at 10:20 +0000, Yao Qi wrote:
> 
> > I believe most of the new failures are due to two problems.  One is
> > unwinding through signal handlers and the other is accessing thread
> Do the answers in this thread help?
> https://sourceware.org/ml/gdb/2017-02/msg00056.html

I have been looking at the code and offsets used in aarch64_linux_sigframe_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 long
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
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.

arch/arm64/kernel/signal.c has:

struct rt_sigframe {
        struct siginfo info;
        struct sigframe sig;
};

but arch/arm64/kernel/signal_ilp32.c (this is part of the kernel
patch set that has been submitted but not yet checked in) has:

struct ilp32_rt_sigframe {
        struct compat_siginfo info;
        struct ilp32_sigframe sig;
};


I think the definitions of siginfo (in LP64 mode from 
include/uapi/asm-generic/siginfo.h and compat_siginfo
from arch/arm64/include/asm/compat.h match up.  So that
should not be different.

sigframe (LP64) is defined in signal.c as:

struct sigframe {
        struct ucontext uc;
        u64 fp;
        u64 lr;
};

struct ucontext {
        unsigned long     uc_flags;
        struct ucontext  *uc_link;
        stack_t           uc_stack;
        struct sigcontext uc_mcontext;
        sigset_t          uc_sigmask;   /* mask last for extensibility */
};

and ilp32_sigframe is:

struct ilp32_sigframe {
        struct ilp32_ucontext uc;
        u64 fp;
        u64 lr;
};
struct ilp32_ucontext {
        u32             uc_flags;
        u32             uc_link;
        compat_stack_t  uc_stack;
        compat_sigset_t uc_sigmask;
        /* glibc uses a 1024-bit sigset_t */
        __u8            __unused[1024 / 8 - sizeof(compat_sigset_t)];
        /* last for future expansion */
        struct sigcontext uc_mcontext;
};

These context structures have differences but I don't know what to do with
them.

Steve Ellcey
sellcey@cavium.com


  reply	other threads:[~2017-03-07 19:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-06 22:03 Steve Ellcey
2017-03-07 10:20 ` Yao Qi
2017-03-07 19:55   ` Steve Ellcey [this message]
2017-03-09 13:24     ` Yao Qi
2017-03-09 17:33       ` Steve Ellcey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1488916527.22552.8.camel@caviumnetworks.com \
    --to=sellcey@caviumnetworks.com \
    --cc=gdb-patches@sourceware.org \
    --cc=qiyaoltc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox