public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Kamil Rytarowski <n54@gmx.com>
To: John Baldwin <jhb@FreeBSD.org>, gdb-patches@sourceware.org
Cc: tom@tromey.com
Subject: Re: [PATCH v3] Add support for "info auxv" on NetBSD
Date: Fri, 27 Mar 2020 18:04:00 +0100	[thread overview]
Message-ID: <09e82a84-db6d-3fed-cf4e-67208cb14ff3@gmx.com> (raw)
In-Reply-To: <39c2ef17-89b2-7c7e-e806-0085de678c5b@FreeBSD.org>

On 27.03.2020 17:31, John Baldwin wrote:
> On 3/26/20 4:26 PM, Kamil Rytarowski wrote:
>> Ping?
>>
>> On 20.03.2020 18:27, Kamil Rytarowski wrote:
>>> Register nbsd_auxv_parse() that overloads the default (Linux-style)
>>> AUXV parsing. On NetBSD the type parameter is defined as int32_t
>>> for all architectures.
>
> I would tone down some of the rhetoric.  FreeBSD uses the default AUXV
> parsing, and I think Solaris does as well, so describing it as Linux-only
> isn't very accurate.
>

It is phrases as Linux-style, not Linux-only.

Linux-style is considered as the default one and other OSs have to tune it.

> (Similarly, I think the earlier reviews I saw around ptrace() claimed that
> NetBSD was the only OS to use LWPs with ptrace() in the log messages in
> effect which isn't really true as both Solaris and FreeBSD use LWPs
> happily with ptrace(), just using a different convention.)
>

The pair of (PID+LWP) for getters and setters of registers (among
certain other ptrace operations) is NetBSD style ptrace(2) API design.
This leads to the point that NetBSD is currently the only OS where
get_ptrace_pid() is not compatible (at leat in the current form).

>>>  }
>>> +
>>> +/* NetBSD-specific parser for AUXV data with. NetBSD follows the ELF
>>> +   specification, contrary to some other ELF Operating Systems.  */
>
> I would also tone this down a bit, and at least reference the correct
> specification.  The ELF spec doesn't define the layout of auxv_t.  The
> per-architecture psABI documents do.  Also, just saying that you follow
> the spec doesn't help.  I would suggest something like:
>
> /* NetBSD-specific parser for AUXV entries.  NetBSD always uses an int
>    to store the type as defined in the SVR4 psABI specifications rather
>    than long as assumed by the default parser.  */
>

This is toned down compared to obsd-tdet.c, that says:

/* Unlike Linux, OpenBSD actually follows the ELF standard.  */

OK, is this patch fine after rephrasing the above texts?

  reply	other threads:[~2020-03-27 17:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-14 18:22 [PATCH] Correct decoding AUXV " Kamil Rytarowski
2020-03-16 13:25 ` Tom Tromey
2020-03-16 18:17   ` Kamil Rytarowski
2020-03-16 18:17 ` [PATCH v2] Add support for "info auxv" " Kamil Rytarowski
2020-03-19 13:11   ` Kamil Rytarowski
2020-03-20 15:43   ` Tom Tromey
2020-03-20 17:27     ` Kamil Rytarowski
2020-03-20 17:27   ` [PATCH v3] " Kamil Rytarowski
2020-03-26 23:26     ` Kamil Rytarowski
2020-03-27 16:31       ` John Baldwin
2020-03-27 17:04         ` Kamil Rytarowski [this message]
2020-03-27 19:22           ` John Baldwin
2020-03-29 20:35             ` Kamil Rytarowski
2020-03-29 22:10     ` Simon Marchi

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=09e82a84-db6d-3fed-cf4e-67208cb14ff3@gmx.com \
    --to=n54@gmx.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jhb@FreeBSD.org \
    --cc=tom@tromey.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).