Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Der Herr Hofrat <der.herr@hofr.at>
To: gdb@sourceware.org
Subject: /gdb/regcache.c question
Date: Sun, 02 Apr 2006 07:45:00 -0000	[thread overview]
Message-ID: <200604030757.k337vhj22619@hofr.at> (raw)


Hi !

 while implementing tracepoints I ran acros a little problem with 
 gdb/regcache.c - the behavior is not really an error its just overly 
 strict for interactive input, obviously regache.c is assuming 
 automatic generation of registers lists only.

(gdb) actions
Enter actions for tracepoint 1, one per line.
End with a line saying just "end".
> collect $regs
> end
(gdb) trace junk2
Tracepoint 2 at 0x80483eb: file hello.c, line 27.
(gdb) actions
Enter actions for tracepoint 2, one per line.
End with a line saying just "end".
> collect $sp
regcache.c:163: internal-error: register_type: Assertion `regnum >= 0 && regnum
< descr->nr_cooked_registers' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

regcache.c:163: internal-error: register_type: Assertion `regnum >= 0 && regnum
< descr->nr_cooked_registers' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y

 
 The trigger is gdb_assert in line 163:

gdb/regcache.c:159-165
struct type *
register_type (struct gdbarch *gdbarch, int regnum)
{
  struct regcache_descr *descr = regcache_descr (gdbarch);
  gdb_assert (regnum >= 0 && regnum < descr->nr_cooked_registers);
  return descr->register_type[regnum];
}


 So a simple misstyp of the register name runs into an assertion with a core
 file dumped - this makes sense for automatic generation - but for tracepoints
 you need to manually be able to pass registers with collect $REGNAME , and
 for that case gdb_assert -> corfile is a little harsh on the user.

 So the question is if it is sensible to change all the gdb_assert - which are
 the right way for automatic generated register lists, or if it would be better
 to distinuish between interactive and automatic generation. For the later I
 was trying to figure out a resonable way to know in what context this (and
 other functions) are called - but did not come up with any obvious solution
 yet - hacking it up only for the "collect" command makes no sense in my 
 opinion.

 any suggestions how to handle this would be appreciated. 

thx !
hofrat


             reply	other threads:[~2006-04-02  7:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-02  7:45 Der Herr Hofrat [this message]
2006-04-02 12:44 ` Mark Kettenis
2006-04-02 13:37   ` Der Herr Hofrat
2006-04-02 13:49     ` Mark Kettenis
2006-04-02 16:33       ` Daniel Jacobowitz

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=200604030757.k337vhj22619@hofr.at \
    --to=der.herr@hofr.at \
    --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