From: Kamil Rytarowski <n54@gmx.com>
To: Christian Biesinger <cbiesinger@google.com>
Cc: gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 2/3 v2] Define _KMEMUSER in arm-nbsd-nat.c
Date: Fri, 24 Jan 2020 16:45:00 -0000 [thread overview]
Message-ID: <7a00a471-ab23-a235-d9bb-1d5d574bdacd@gmx.com> (raw)
In-Reply-To: <CAPTJ0XFREXZ67j+FA=bjTAFeUPwBfCz+s2dgRMj7drAJTTYnRw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 5874 bytes --]
On 24.01.2020 17:01, Christian Biesinger wrote:
> On Fri, Jan 24, 2020 at 4:49 PM Kamil Rytarowski <n54@gmx.com> wrote:
>>
>> On 24.01.2020 16:35, Christian Biesinger via gdb-patches wrote:
>>> On Fri, Jan 24, 2020 at 4:23 PM Kamil Rytarowski <n54@gmx.com> wrote:
>>>>
>>>> On 24.01.2020 15:53, Christian Biesinger via gdb-patches wrote:
>>>>> Hi Kamil,
>>>>>
>>>>> I have a related question. NetBSD applied this patch:
>>>>> https://www.mail-archive.com/tech@openbsd.org/msg44100.html
>>>>>
>>>>
>>>> Is this the right link?
>>>
>>> Yeah -- that patch changes a system header at the top and patches GDB
>>> at the bottom.
>>>
>>
>> This is not a change in NetBSD, so it is unrelated.
>
> My apologies, I completely misread that. I'll see if I can find where
> NetBSD changed their FP register data structure, or perhaps your
> downstream patch will still work (although that probably has to come
> from one of y'all for copyright reasons?)
>
Please cherry-pick what you need and I will find the original author.
Many people in NetBSD have FSF papers done.
>>>>> Do you know which NetBSD version that shipped in? Can we apply that
>>>>> patch to GDB as-is or should we attempt to support the older struct
>>>>> layout as well?
>>>>
>>>> Please go for the current FPU layout on NetBSD. Massive ptrace(2) fixes
>>>> were introduced in NetBSD-8 and later. Soon NetBSD 7.x will go EOL
>>>> (after releasing 9.0, rc2 is planned soon).
>>>
>>> OK, great. Thanks.
>>>
>>>> In LLDB we support NetBSD 9.0 or newer. In GDB we should keep the same
>>>> minimal requirements and deal with older NetBSD versions (if at all)
>>>> with downstream patches.
>>>>
>>>> We have got a pile of local GDB patches.
>>>
>>> OK. Maybe I should look through those at some point... I was
>>> surprised that NetBSD apparently has an oldish GDB if
>>> http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/gdb/README.html
>>> is correct (8.1)
>>>
>>>> There is also a functional gdbserver implementation on NetBSD/amd64 and
>>>> I intend to upstream it. (Help wanted! Would you be interested in this
>>>> and in upstreaming?)
>>>>
>>>> The patches are located here:
>>>>
>>>> https://github.com/NetBSD/pkgsrc-wip/tree/master/gdb-netbsd/patches
>>>>
>>>> * with core/basic features... but it is difficult as there is no OS with
>>>> finished transition...
>>>> https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity
>>>
>>> I can definitely not commit to upstreaming the gdbserver. I am only
>>> looking at NetBSD because I wanted to remove a deprecated function in
>>> GDB, and one of the two callers is in NetBSD ARM code. So, I wanted to
>>> build ARM NetBSD first so I can test if it still works after that
>>> change. But I can't commit to any further NetBSD work.
>>>
>>
>> OK, thanks!
>>
>>> BTW, is there a reason why your patches have one .patch per changed
>>> file? I usually find it easier to follow them if they are instead
>>> grouped by some kind of topic per patch.
>>>
>>
>> This is a convention in pkgsrc and it is practical for its use-case.
>
> OK. Some of those patches should be upstreamable very easily. For some
> others it would be helpful to have a description & I guess a copyright
> assignment.
>
My intention was to revamp the general NetBSD support from native-only
to gdbserver... (same like lldb-server).. and it would result in deep
rewrite of the current code, but there is work in progress status in
Linux so it does not help.
> I also noticed that some of those files are 0 bytes and could probably
> be deleted? And this does not seem necessary:
> https://github.com/NetBSD/pkgsrc-wip/blob/master/gdb-netbsd/patches/patch-bfd_netbsd-core.c
>
Good catch.
>>>>>
>>>>> Thanks,
>>>>> Christian
>>>>>
>>>>> On Fri, Jan 24, 2020 at 3:29 PM Kamil Rytarowski <n54@gmx.com> wrote:
>>>>>>
>>>>>> On 24.01.2020 15:18, cbiesinger@chromium.org wrote:
>>>>>>> From: Christian Biesinger <cbiesinger@google.com>
>>>>>>>
>>>>>>> Fixes the below compile error on ARM NetBSD 9.0_RC1 (the only version I
>>>>>>> tested). types.h does not define register_t by default.
>>>>>>>
>>>>>>> We already use this define elsewhere, notably in bsd-kvm.c.
>>>>>>>
>>>>>>> In file included from ../../gdb/arm-nbsd-nat.c:28:
>>>>>>> /usr/include/machine/frame.h:54:2: error: unknown type name 'register_t'; did you mean '__register_t'?
>>>>>>> register_t tf_spsr;
>>>>>>> ^
>>>>>>> /usr/include/machine/types.h:77:14: note: '__register_t' declared here
>>>>>>> typedef int __register_t;
>>>>>>> ^
>>>>>>>
>>>>>>> There are other compile errors that this does not fix.
>>>>>>>
>>>>>>> gdb/ChangeLog:
>>>>>>>
>>>>>>> 2020-01-24 Christian Biesinger <cbiesinger@google.com>
>>>>>>>
>>>>>>> * arm-nbsd-nat.c: Define _KMEMUSER to get the declaration of
>>>>>>> register_t.
>>>>>>>
>>>>>>> Change-Id: I82c21d38189ee59ea0af2538ba84b771d268722e
>>>>>>> ---
>>>>>>> gdb/arm-nbsd-nat.c | 2 ++
>>>>>>> 1 file changed, 2 insertions(+)
>>>>>>>
>>>>>>> diff --git a/gdb/arm-nbsd-nat.c b/gdb/arm-nbsd-nat.c
>>>>>>> index 00f919194b..4844b51a3c 100644
>>>>>>> --- a/gdb/arm-nbsd-nat.c
>>>>>>> +++ b/gdb/arm-nbsd-nat.c
>>>>>>> @@ -17,6 +17,8 @@
>>>>>>> You should have received a copy of the GNU General Public License
>>>>>>> along with this program. If not, see <http://www.gnu.org/licenses/>. */
>>>>>>>
>>>>>>> +/* We define this to get types like register_t. */
>>>>>>> +#define _KMEMUSER
>>>>>>> #include "defs.h"
>>>>>>> #include "gdbcore.h"
>>>>>>> #include "inferior.h"
>>>>>>>
>>>>>>
>>>>>> While gdb is the right user for _KMEMUSER, here we should probably go
>>>>>> for -D_KERNTYPES as it is the canonical symbol for register_t.
>>>>>>
>>>>
>>>>
>>
>>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-01-24 16:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-24 14:15 [PATCH 0/3] Fix some ARM NetBSD compile errors cbiesinger
2020-01-24 14:15 ` [PATCH 3/3] Make the class name in the definition match the declaration cbiesinger
2020-01-24 14:54 ` Kamil Rytarowski
2020-01-24 15:06 ` Tom Tromey
2020-01-24 15:49 ` Christian Biesinger via gdb-patches
2020-01-24 14:15 ` [PATCH 1/3] Support the NetBSD version of pthread_setname_np cbiesinger
2020-01-24 14:59 ` Kamil Rytarowski
2020-01-24 15:04 ` Tom Tromey
2020-01-24 14:18 ` [PATCH 2/3] Define _KMEMUSER in arm-nbsd-nat.c cbiesinger
2020-01-24 14:22 ` [PATCH 2/3 v2] " cbiesinger
2020-01-24 14:32 ` Kamil Rytarowski
2020-01-24 14:34 ` Christian Biesinger via gdb-patches
2020-01-24 14:36 ` [PATCH v3 2/3] Define _KERNTYPES " cbiesinger
2020-01-24 15:04 ` Tom Tromey
2020-01-24 14:58 ` [PATCH 2/3 v2] Define _KMEMUSER " Christian Biesinger via gdb-patches
2020-01-24 15:36 ` Kamil Rytarowski
2020-01-24 15:37 ` Christian Biesinger via gdb-patches
2020-01-24 15:49 ` Kamil Rytarowski
2020-01-24 16:25 ` Christian Biesinger via gdb-patches
2020-01-24 16:45 ` Kamil Rytarowski [this message]
2020-01-27 21:28 ` Christian Biesinger via gdb-patches
2020-02-05 18:02 ` Christian Biesinger via gdb-patches
2020-02-06 13:25 ` Kamil Rytarowski
2020-02-06 13:19 ` Kamil Rytarowski
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=7a00a471-ab23-a235-d9bb-1d5d574bdacd@gmx.com \
--to=n54@gmx.com \
--cc=cbiesinger@google.com \
--cc=gdb-patches@sourceware.org \
/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).