From: Simon Marchi <simark@simark.ca>
To: Kamil Rytarowski <n54@gmx.com>, gdb-patches@sourceware.org
Cc: tom@tromey.com
Subject: Re: [PATCH v2 10/10] Add minimal and functional NetBSD/amd64 gdbserver
Date: Mon, 7 Sep 2020 15:58:18 -0400 [thread overview]
Message-ID: <071c608e-0709-6fff-cd42-4981b3d0bdb6@simark.ca> (raw)
In-Reply-To: <20200904002905.13616-11-n54@gmx.com>
I did a superficial review, that's as much as I can, since I can't easily test this. I also don't
know gdbserver by heart, so I can't tell off the top of my head if some method implementation doesn't
match what's expected, for example.
So I checked for obvious mistakes (didn't find any) and coding standards (looks pretty good). Since
this is new code, I am not too worried, it won't break any existing use case. The worst that can happen
is that there are bugs and we fix them later.
On 2020-09-03 8:29 p.m., Kamil Rytarowski wrote:
> Implement the following functionality: create_inferior,
> post_create_inferior, attach, kill, detach, mourn, join, thread_alive,
> resume, wait, fetch_registers, store_registers, read_memory, write_memory,
> request_interrupt, supports_read_auxv, read_auxv,
> supports_hardware_single_step, sw_breakpoint_from_kind,
> supports_z_point_type, insert_point, remove_point,
> stopped_by_sw_breakpoint, supports_qxfer_siginfo, qxfer_siginfo,
> supports_stopped_by_sw_breakpoint, supports_non_stop,
> supports_multi_process, supports_fork_events, supports_vfork_events,
> supports_exec_events, supports_disable_randomization,
> supports_qxfer_libraries_svr4, qxfer_libraries_svr4,
> supports_pid_to_exec_file, pid_to_exec_file, thread_name,
> supports_catch_syscall.
>
> The only CPU architecture supported: x86_64.
>
> Implement only support for hardware assisted single step and
> software breakpoint.
>
> Implement support only for regular X86 registers, thus no FPU.
>
> gdbserver/ChangeLog:
>
> * netbsd-low.cc: Add.
> * netbsd-low.h: Likewise.
> * netbsd-x86_64-low.cc: Likewise.
Let's name this new file netbsd-amd64-low.cc. We use amd64 everywhere, so it's
better to stay consistent.
> +/* Implement the fetch_registers target_ops method. */
> +
> +void
> +netbsd_process_target::fetch_registers (struct regcache *regcache, int regno)
> +{
> + struct netbsd_regset_info *regset = netbsd_target_regsets;
> + ptid_t inferior_ptid = ptid_of (current_thread);
> +
> + while (regset->size >= 0)
> + {
> + char *buf = (char *) xmalloc (regset->size);
> + int res = ptrace (regset->get_request, inferior_ptid.pid (), buf,
> + inferior_ptid.lwp ());
> + if (res == -1)
> + perror_with_name (("ptrace"));
> + regset->store_function (regcache, buf);
> + free (buf);
The perror would leak `buf`. Use some automatic memory management type.
> + regset++;
> + }
> +}
> +
> +/* Implement the store_registers target_ops method. */
> +
> +void
> +netbsd_process_target::store_registers (struct regcache *regcache, int regno)
> +{
> + struct netbsd_regset_info *regset = netbsd_target_regsets;
> + ptid_t inferior_ptid = ptid_of (current_thread);
> +
> + while (regset->size >= 0)
> + {
> + char *buf = (char *)xmalloc (regset->size);
> + int res = ptrace (regset->get_request, inferior_ptid.pid (), buf,
> + inferior_ptid.lwp ());
> + if (res == -1)
> + perror_with_name (("ptrace"));
> + if (res == 0)
> + {
> + /* Then overlay our cached registers on that. */
> + regset->fill_function (regcache, buf);
> + /* Only now do we write the register set. */
> + res = ptrace (regset->set_request, inferior_ptid.pid (), buf,
> + inferior_ptid.lwp ());
> + }
> + free (buf);
Same here.
> +/* Extract &phdr and num_phdr in the inferior. Return 0 on success. */
> +
> +template <typename T>
> +int get_phdr_phnum_from_proc_auxv (const pid_t pid,
> + CORE_ADDR *phdr_memaddr, int *num_phdr)
> +{
> + typedef typename std::conditional<sizeof(T) == sizeof(int64_t),
> + Aux64Info, Aux32Info>::type auxv_type;
> + const size_t auxv_size = sizeof (auxv_type);
> + const size_t auxv_buf_size = 128 * sizeof (auxv_type);
> +
> + char *auxv_buf = (char *) xmalloc (auxv_buf_size);
> +
> + netbsd_read_auxv (pid, nullptr, auxv_buf, auxv_buf_size);
> +
> + *phdr_memaddr = 0;
> + *num_phdr = 0;
> +
> + for (char *buf = auxv_buf; buf < (auxv_buf + auxv_buf_size); buf += auxv_size)
> + {
> + auxv_type *const aux = (auxv_type *) buf;
> +
> + switch (aux->a_type)
> + {
> + case AT_PHDR:
> + *phdr_memaddr = aux->a_v;
> + break;
> + case AT_PHNUM:
> + *num_phdr = aux->a_v;
> + break;
> + }
> +
> + if (*phdr_memaddr != 0 && *num_phdr != 0)
> + break;
> + }
> +
> + xfree (auxv_buf);
Same here.
> +struct regcache;
> +struct target_desc;
> +
> +/* Some information relative to a given register set. */
> +
> +struct netbsd_regset_info
> +{
> + /* The ptrace request needed to get/set registers of this set. */
> + int get_request, set_request;
> + /* The size of the register set. */
> + int size;
> + /* Fill the buffer BUF from the contents of the given REGCACHE. */
> + void (*fill_function) (struct regcache *regcache, char *buf);
> + /* Store the register value in BUF in the given REGCACHE. */
> + void (*store_function) (struct regcache *regcache, const char *buf);
I find the distinction between "fill" and "store" unclear, it doesn't really tell
which direction it's going (looking at the types helps though). fill the regcache?
fill the buffer? store in the regcache? store in the buffer?
It's the same with the regcache::supply_regset and regcache::collect_regset methods
in GDB... I never know what supply and collect mean. Are they from the point of view
of the regset? Or from the point of view of the user of the regset?
What about:
void (*buf_to_regcache) (struct regcache *regcache, char *buf);
void (*regcache_to_buf) (struct regcache *regcache, const char *buf);
You could add the `_function` suffix if you prefer, though I don't think it's necessary.
Simon
next prev parent reply other threads:[~2020-09-07 19:58 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 0:28 [PATCH v2 00/10] Add minimal NetBSD/amd64 gdbserver support Kamil Rytarowski
2020-09-04 0:28 ` [PATCH v2 01/10] Add handle_eintr to wrap EINTR handling in syscalls Kamil Rytarowski
2020-09-07 14:06 ` Simon Marchi
2020-09-07 14:59 ` Kamil Rytarowski
2020-10-12 17:56 ` [PATCH] gdb::handle_eintr, remove need to specify return type (Re: [PATCH v2 01/10] Add handle_eintr to wrap EINTR handling in syscalls) Pedro Alves
2020-10-13 13:43 ` Kamil Rytarowski
2020-10-13 14:17 ` [PATCH v2] gdb::handle_eintr, remove need to specify return type Pedro Alves
2020-10-13 14:54 ` Kamil Rytarowski
2020-10-16 20:51 ` Tom Tromey
2020-10-26 14:00 ` Pedro Alves
2020-10-26 14:20 ` Tom Tromey
2020-10-26 18:59 ` Pedro Alves
2020-09-04 0:28 ` [PATCH v2 02/10] Register a placeholder for NetBSD shared functions in gdb/nat Kamil Rytarowski
2020-09-07 18:44 ` Simon Marchi
2020-09-07 19:49 ` Kamil Rytarowski
2020-09-04 0:28 ` [PATCH v2 03/10] Build nat/netbsd-nat.o for the NetBSD native target Kamil Rytarowski
2020-09-04 0:28 ` [PATCH v2 04/10] Add netbsd_nat::pid_to_exec_file Kamil Rytarowski
2020-09-07 7:57 ` Andrew Burgess
2020-09-07 13:36 ` Kamil Rytarowski
2020-09-07 18:48 ` Simon Marchi
2020-09-07 18:47 ` Simon Marchi
2020-09-07 19:51 ` Kamil Rytarowski
2020-09-04 0:29 ` [PATCH v2 05/10] Add gdb/nat common functions for listing threads Kamil Rytarowski
2020-09-07 18:59 ` Simon Marchi
2020-09-07 19:57 ` Kamil Rytarowski
2020-09-04 0:29 ` [PATCH v2 06/10] Add netbsd_nat::enable_proc_events in gdb/nat Kamil Rytarowski
2020-09-04 0:29 ` [PATCH v2 07/10] Add a common utility function to read and write siginfo_t in inferior Kamil Rytarowski
2020-09-04 0:29 ` [PATCH v2 08/10] Avoid double free in startup_inferior Kamil Rytarowski
2020-09-07 19:19 ` Simon Marchi
2020-09-08 0:54 ` Kamil Rytarowski
2020-09-08 2:21 ` Simon Marchi
2020-09-04 0:29 ` [PATCH v2 09/10] Switch local native code to gdb/nat shared functions Kamil Rytarowski
2020-09-07 19:24 ` Simon Marchi
2020-09-08 0:04 ` Kamil Rytarowski
2020-09-04 0:29 ` [PATCH v2 10/10] Add minimal and functional NetBSD/amd64 gdbserver Kamil Rytarowski
2020-09-07 19:58 ` Simon Marchi [this message]
2020-09-08 0:03 ` 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=071c608e-0709-6fff-cd42-4981b3d0bdb6@simark.ca \
--to=simark@simark.ca \
--cc=gdb-patches@sourceware.org \
--cc=n54@gmx.com \
--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