This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2 1/3] RISC-V/Linux/native: Determine FLEN dynamically
- From: Jim Wilson <jimw at sifive dot com>
- To: "Maciej W. Rozycki" <macro at wdc dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Andrew Burgess <andrew dot burgess at embecosm dot com>, Palmer Dabbelt <palmer at dabbelt dot com>, Tom Tromey <tom at tromey dot com>, "guoren at kernel dot org" <guoren at kernel dot org>, "lifang_xia at c-sky dot com" <lifang_xia at c-sky dot com>, "yunhai_shang at c-sky dot com" <yunhai_shang at c-sky dot com>, "jiangshuai_li at c-sky dot com" <jiangshuai_li at c-sky dot com>
- Date: Thu, 30 Jan 2020 14:56:29 -0800
- Subject: Re: [PATCH v2 1/3] RISC-V/Linux/native: Determine FLEN dynamically
- References: <alpine.LFD.2.21.2001291207310.14118@redsun52.ssa.fujisawa.hgst.com> <alpine.LFD.2.21.2001291410310.14118@redsun52.ssa.fujisawa.hgst.com>
On Wed, Jan 29, 2020 at 10:13 AM Maciej W. Rozycki <macro@wdc.com> wrote:
> We can do better however and not rely on any particular value of FLEN
> and probe for it dynamically, by observing that the PTRACE_GETREGSET
> ptrace(2) call will only accept an exact regset size, and that will
> reflect FLEN.
I forgot to mention this before, but our long term plans are to pass
info via the auxiliary vector from the kernel to the application, and
then in theory gdb should be able to get architecture info from there.
This may require support that hasn't been written yet, and we may
still need the fp probing for older systems that don't have all of the
support needed to make aux vec work. Just with a quick check on my
4.15 kernel, I see
hifiveu017:1030$ ./a.out
AT_HWCAP = 0x1105
that is 'a', 'c', 'i', and 'm', each represented as 1<<(x-'a'). The
'f' and 'd' info is missing for some reason. Maybe it hadn't been
implemented yet in this kernel version.
Jim