Omair, can you check? I suppose this is also present upstream?

This issue doesnt appear on my side.

I have tried TOT GDB from upstream master as well the arm release gcc-arm-8.2-2019.01-x86_64-arm-linux-gnueabihf.

This seems to be faulty gdbserver exchanging all these registers in target description xml. Thats why these registers are being shown as part of info registers command.

Joakim,
Are you using system gdbserver or gdbserver binary from the toolchain tarball?

(In reply to Maxim Kuvyrkov from comment #3)
> Joakim,
> Are you using system gdbserver or gdbserver binary from the toolchain
> tarball?

I see, in this particular case I'm attaching to QEMU with '-s', i.e., QEMU brings up a gbdserver in some way and sits and wait for someone to attach (from the QEMU help, "-s              shorthand for -gdb tcp::1234").

So are you saying that this could be an issue with QEMU in that case and not the toolchain? If yes, then I wonder what has changed, since if I use an older GCC, like GCC6.x, then things works as expected (with the same version of QEMU).

The way I'm running this is using two consoles (if you omit the "<and-a-bunch-of-other-args>" then you should be able to reproduce this on your side (I just tested it without running any particular binaries):

console 1:
----------
$ qemu-system-arm -s -machine virt,secure=on -cpu cortex-a15 <and-a-bunch-of-other-args>

console 2:
----------
$ ./arm-linux-gnueabihf-gdb -q
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x00000000 in ?? ()
(gdb) info registers
r0             0x0	0x0
r1             0x0	0x0
r2             0x0	0x0
r3             0x0	0x0
r4             0x0	0x0
r5             0x0	0x0
r6             0x0	0x0
r7             0x0	0x0
r8             0x0	0x0
r9             0x0	0x0
r10            0x0	0x0
r11            0x0	0x0
r12            0x0	0x0
sp             0x0	0x0
lr             0x0	0x0
pc             0x0	0x0
cpsr           0x400001d3	0x400001d3
fpscr          0x0	0x0
fpsid          0x410430f0	0x410430f0
fpexc          0x0	0x0
CLIDR_S        0xa200023	0xa200023
DBGBCR         0x0	0x0
...

Hi Joakim,

What's QEMU version?

(In reply to Maxim Kuvyrkov from comment #5)
> Hi Joakim,
> 
> What's QEMU version?

$ qemu-system-arm --version
QEMU emulator version 3.0.93 (v3.1.0-rc3-dirty)

$ git remote -v
github  https://github.com/qemu/qemu.git (fetch)
github  https://github.com/qemu/qemu.git (push)

$ git log -1
commit 4750e1a888ac3d320607f33b676f299005be98e6 (grafted, HEAD, tag: v3.1.0-rc3, tag: m/master)
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Wed Nov 28 17:37:34 2018 +0000

    Update version for v3.1.0-rc3 release
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

// Regards
Joakim

There has been changes to gdb's handling with target description xml. These changes have been made to make way for SVE patches. There is a high chance that QEMU gdbserver is not complying with new changes.

Hi Joakim,

Please share gdb remote communication log by setting log file in gdb at the start of debug session.

gdb) set remotelogfile file

Lets see what packets and registers description gdb and qemu stub are exchanging in this case.

Created attachment 1027 [details]
This file contains a remotelog from GDB

So the problem seems to be with group field for new registers being added by QEMU. GDB info registers will show all registers under a specified group. If no group is specified those registers will be omitted from info registers output.

Here a excerpt from gdb documentation:

@item group
The register group to which this register belongs.  It can be one of the
standard register groups @code{general}, @code{float}, @code{vector} or an
arbitrary string.  Group names should be limited to alphanumeric characters.
If a group name is made up of multiple words the words may be separated by
hyphens; e.g.@: @code{special-group} or @code{ultra-special-group}.  If no
@var{group} is specified, @value{GDBN} will not display the register in
@code{info registers}.

For example from the output of rsp log attached by Joakim:

 <reg name="q14" bitsize="128" type="neon_q"/>\n  <reg name="q15" bitsize="128" type="neon_q"/>\n\n  <reg name="fpsid" bitsize="32" type="int" group="float"/>\n  <reg name="fpscr" bitsize="32" type="int" group="float"/>\n  <reg name="fpexc" bitsize="32" type="int" group="float"/>

no group is specified for q registers but group float is specified for fpscr and fpexc.

Created attachment 1043 [details]
This change updates gdb to add user defined reg groups.

This attached patch allows use or arbitrary strings for register group in gdb target description xml.

This may help fix this bug.

Omar, if/when you know if there is a toolchain with the fix applied and ready for download, please let me know and I'll give it a try. Thanks for the update!

// Joakim

I have suggested a few changes to qemu, which will at least
"fix" this for qemu-arm (i.e. user-only) debugging, but will
still have the same problem for qemu-system-arm.

https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02318.html

However, I believe there is still a problem with gdb.

In particular, the ultimate fallback is default_register_reggroup_p,
which assigns all registers with integral type to "general", in
addition to whatever group to which they have been explicitly assigned.

You can see this even with the "normal" user registers.
From maint print reggroups:

 fpscr        90   90    324       4 long     \
       general,float,all,save,restore

We assigned fpscr to "float", but because it has type uint32_t
it has also been assigned to "general".  Which means that it is
indeed printed with "info reg".

While this appears to be by design, I think this is is a mistake.

Opened an upstream bug for this:
https://sourceware.org/bugzilla/show_bug.cgi?id=24361