From: "Philippe Waroquiers" <philippe.waroquiers@skynet.be>
To: <gdb@sourceware.org>
Subject: gdbserver target description: info reg displays or not according to group presence ???
Date: Fri, 30 Jul 2010 22:16:00 -0000 [thread overview]
Message-ID: <626075219D624850B89B9E0A39D09734@soleil> (raw)
Hello,
I am busy integrating a gdbserver within valgrind.
Valgrind has shadow registers (indicating if a register contains
"uninitialized" data).
To have gdb be able to display and modify these registers, I am defining
a target description that includes the normal register set and the 2
valgrind shadow register sets.
I would like that these registers are not shown in "info regs" but
only shown in "info all-reg".
According to the manual (gdb gdb-7.2.50.20100730), it is enough
to *not* specify a group and then these are not displayed:
GROUP
The register group to which this register belongs. GROUP must be
either `general', `float', or `vector'. If no GROUP is specified,
GDB will not display the register in `info registers'.
However, that does not seem to match what I observe.
The file gdb/features/i386/32bit-core.xml defines e.g. eax as:
<reg name="eax" bitsize="32" type="int32"/>
This register is shown in info reg.
According to the manual above, it should not.
I have defined another file for valgrind, called 32bit-core-valgrind-s1.xml
where I have a.o. the following two lines:
<reg name="eaxs1" bitsize="32" type="int32" group="s1"/>
<reg name="ecxs1" bitsize="32" type="int32"/>
When I am doing info regs, gdb shows both eaxs1 and ecxs1 (and all others
shadow registers).
Looking at the trace, I see that the correct description is returned
to gdb. I see that gdb properly has understood the target description
as it shows the normal and shadow registers.
However, it does always shows all the shadow registers, not taking
into account the presence or not of a group.
Trying to understand what is happening, I am using maint print
to look at what gdb has understood:
(gdb) maint print c-tdesc
The current target description did not come from an XML file.
-- this looks normal as the target description arrives from gdbserver.
(gdb) maint print register-groups
... (removed some)
'' 47 47 308 0 int0_t general
'' 48 48 308 0 int0_t general
orig_eax 49 49 308 4 long save,restore,system
eaxs1 50 50 312 4 int32_t general,all,save,restore
ecxs1 51 51 316 4 int32_t general,all,save,restore
edxs1 52 52 320 4 int32_t general,all,save,restore
... (removed some)
-- this looks strange: the s1 group is not theree for eaxs1, it rather has general/all/save/restore
indication.
(gdb) maint print raw-registers
... (removed some)
'' 47 47 308 0 int0_t <invalid>
'' 48 48 308 0 int0_t <invalid>
orig_eax 49 49 308 4 long 0x00000000
eaxs1 50 50 312 4 int32_t 0x00000000
ecxs1 51 51 316 4 int32_t 0x00000000
edxs1 52 52 320 4 int32_t 0x00000000
... (removed some)
So, there is something that looks wrong.
Any hint/idea ?
next reply other threads:[~2010-07-30 22:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-30 22:16 Philippe Waroquiers [this message]
2010-08-02 2:39 ` Daniel Jacobowitz
2010-08-02 18:07 ` Philippe Waroquiers
2010-08-11 20:23 ` Daniel Jacobowitz
2010-08-12 19:08 ` Philippe Waroquiers
2010-09-12 11:09 ` Philippe Waroquiers
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=626075219D624850B89B9E0A39D09734@soleil \
--to=philippe.waroquiers@skynet.be \
--cc=gdb@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