/gdb/regcache.c question

/gdb/regcache.c question

[Der Herr Hofrat]

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

Re: /gdb/regcache.c question

[Mark Kettenis]

> From: Der Herr Hofrat <der.herr@hofr.at>
> Date: Mon, 3 Apr 2006 09:57:43 +0200 (CEST)
> 
> 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.

I don't understand what you're doing here, but that gdb_assert (and
all gdb_asserts in the code) is checking for a "should not happen"
condition.  If you hit one, it means there's a bug in some other piece
of gdb code.  You should find and fix that bug.

Mark

Re: /gdb/regcache.c question

[Der Herr Hofrat]

> > From: Der Herr Hofrat <der.herr@hofr.at>
> > Date: Mon, 3 Apr 2006 09:57:43 +0200 (CEST)
> > 
> > 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.
> 
> I don't understand what you're doing here, but that gdb_assert (and
> all gdb_asserts in the code) is checking for a "should not happen"
> condition.  If you hit one, it means there's a bug in some other piece
> of gdb code.  You should find and fix that bug.
> 
the bug is a simple typo in a collect command - if you type in 
$pc on x86 it will give you the above assertion if you use any 
actually defined registers all is fine (and data is collected)
My assumption is that the assertion was put in there to catch 
incorrect register names that are generated automatically, but
not interactively.

hofrat

Re: /gdb/regcache.c question

[Mark Kettenis]

> From: Der Herr Hofrat <der.herr@hofr.at>
> Date: Mon, 3 Apr 2006 15:49:14 +0200 (CEST)
> 
> > > 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.
> > 
> > I don't understand what you're doing here, but that gdb_assert (and
> > all gdb_asserts in the code) is checking for a "should not happen"
> > condition.  If you hit one, it means there's a bug in some other piece
> > of gdb code.  You should find and fix that bug.
> > 

> the bug is a simple typo in a collect command - if you type in 
> $pc on x86 it will give you the above assertion if you use any 
> actually defined registers all is fine (and data is collected)
> My assumption is that the assertion was put in there to catch 
> incorrect register names that are generated automatically, but
> not interactively.

No, the bug is that the code that parses your collect command is
asking for the type of a register number that doesn't exist.  That
typo should have been caught much earlier before register_type() was
called.

Mark

Re: /gdb/regcache.c question

[Daniel Jacobowitz]

On Sun, Apr 02, 2006 at 03:49:44PM +0200, Mark Kettenis wrote:
> No, the bug is that the code that parses your collect command is
> asking for the type of a register number that doesn't exist.  That
> typo should have been caught much earlier before register_type() was
> called.

The most useful thing to provide when you hit an abort is the
backtrace.  Then we can figure out where the real bug is.

This one's easy to reproduce.  regnum == 51, descr->nr_cooked_registers
== 50.  It turns out that the problem is "user registers", which are
implemented sort of off to the side of the regcache. 
user_reg_map_name_to_regnum returns 51 for i386's "pc".

0 <= x < NUM_REGS : raw registers
NUM_REGS <= x < NUM_REGS + NUM_PSEUDO_REGS : cooked pseudo registers
NUM_REGS + NUM_PSEUDO_REGS <= x : "user" registers

The only thing that user registers have is a value, and you can get at
their type through the value.  The user-regs and std-regs
infrastructure isn't much used; I don't know what the plan was for it. 
I don't think we can collect user registers without changing the
interface.

It is only used for $pc, $sp, $fp, and $ps.  For $sp and $ps it either
returns a normal register or an error.  For $fp and $pc it's a bit more
complicated.

Anyway, for now the easiest thing to do would be to refuse to collect
registers >= NUM_REGS + NUM_PSEUDO_REGS.

-- 
Daniel Jacobowitz
CodeSourcery