All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chung-Lin Tang <cltang@codesourcery.com>
To: Ley Foon Tan <lftan@altera.com>,
	Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Cc: Chung-Lin Tang <chunglin.tang@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Tobias Klauser <tklauser@distanz.ch>,
	Walter Goossens <waltergoossens@home.nl>,
	Linux-Arch <linux-arch@vger.kernel.org>,
	"nios2-dev@lists.rocketboards.org"
	<nios2-dev@lists.rocketboards.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: nios2: is the ptrace ABI correct?
Date: Tue, 10 Mar 2015 14:17:29 +0800	[thread overview]
Message-ID: <54FE8C79.2000104@codesourcery.com> (raw)
In-Reply-To: <CAFiDJ5_gstXn-y8JSzi=gy+nRrrFqCaQA_R4CVg0+vhLz1EZPw@mail.gmail.com>

On 2015/3/10 10:54 AM, Ley Foon Tan wrote:
> On Tue, Mar 10, 2015 at 1:05 AM, Ezequiel Garcia
> <ezequiel@vanguardiasur.com.ar> wrote:
>>
>>
>> On 03/09/2015 02:02 PM, Chung-Lin Tang wrote:
>>> On 2015/3/10 12:54 AM, Chung-Lin Tang wrote:
>>>> It appears that some of the ways nios2 has organized the
>>>> ucontext/pt_regs/etc. are remnants of the pre-generic code, some
>>>> basically because the port was based off m68k.
>>>>
>>>> I've re-organized the headers a bit: nios2/include/asm/ucontext.h is
>>>> deleted, and re-definition of struct sigcontext now allows use of
>>>> uapi/asm-generic/ucontext.h directly.  Note that the reorg, despite
>>>> effectively renaming some fields, is still binary compatible. I'll
>>>> probably update the corresponding glibc definitions later.
>>>>
>>>> struct pt_regs is now not exported, and all exported register sets are
>>>> now supposed to follow the 49 register set defined as in GDB now.
>>>>
>>>> Tobias, Ley Foon, how do you think this looks?
>>>
>>> Sorry, accidentally attached unrelated GCC patch instead, this one's the
>>> correct one.
>>>
>>
>> Looks good. I'm wondering if...
>>
>> +/* User structures for general purpose registers.  */
>> +struct user_pt_regs {
>> +       __u32           regs[49];
>>  };
>>
>> Can we expose the registers explicitly here? Like this:
>>
>> struct user_pt_regs {
>>         __u32 r0;
>>         __u32 r1;
>>         ...
>>         __u32 sp;
>>         __u32 gp;
>>         __u32 estatus;
>> };
>>
>> It looks self-documenting and thus easier to use.
> 
> Hi Chung-Lin,
> 
> Your patch look good to me.
> Do you have any problem to change the struct user_pt_regs based on
> Ezequiel's suggestion?

Well, exposing the register names like that sort of defeats the purpose of
the PTR_* defines.

Judging from the overall trend of style in arch/*/include/uapi/asm/ptrace.h
across ports, I would prefer to stay with the array field.

Thanks,
Chung-Lin

  reply	other threads:[~2015-03-10  6:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-24  3:04 nios2: is the ptrace ABI correct? Ezequiel Garcia
2015-02-24  8:54 ` Arnd Bergmann
2015-02-24 15:28   ` Ezequiel Garcia
2015-02-24 19:25     ` Arnd Bergmann
2015-02-25 11:33       ` Ezequiel Garcia
2015-02-25 14:07         ` Arnd Bergmann
2015-02-27  8:57           ` Chung-Lin Tang
2015-02-27  8:57             ` Chung-Lin Tang
2015-02-27 11:19             ` Ezequiel Garcia
2015-03-04 20:56               ` Ezequiel Garcia
2015-03-09 16:54               ` Chung-Lin Tang
2015-03-09 16:54                 ` Chung-Lin Tang
2015-03-09 17:02                 ` Chung-Lin Tang
2015-03-09 17:05                   ` Ezequiel Garcia
2015-03-10  2:54                     ` Ley Foon Tan
2015-03-10  6:17                       ` Chung-Lin Tang [this message]
2015-03-11  7:48                         ` Ley Foon Tan
2015-03-11 14:31                           ` Ezequiel Garcia
2015-03-12 11:07                   ` Tobias Klauser
  -- strict thread matches above, loose matches on Subject: below --
2015-02-24  2:30 Ezequiel Garcia

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=54FE8C79.2000104@codesourcery.com \
    --to=cltang@codesourcery.com \
    --cc=arnd@arndb.de \
    --cc=chunglin.tang@gmail.com \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=lftan@altera.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nios2-dev@lists.rocketboards.org \
    --cc=tklauser@distanz.ch \
    --cc=waltergoossens@home.nl \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.