The ari hits

The ari hits

[Andrew Cagney]

Daniel,

The files you recently committed trip the ARI.  Can you please check 
this out.

Andrew

http://sources.redhat.com/gdb/current/ari/

Re: The ari hits

[Daniel Jacobowitz]

On Thu, Feb 27, 2003 at 05:09:46PM -0500, Andrew Cagney wrote:
> Daniel,
> 
> The files you recently committed trip the ARI.  Can you please check 
> this out.
> 
> Andrew
> 
> http://sources.redhat.com/gdb/current/ari/

Thanks for reminding me; this patch fixes them.  Almost obvious except
for a bit that I want your opinion on - the hint on the ARI
says to use register_size but I'm not convinced that's right.  Is
gdbarch_register_size always big enough that I don't need to use
gdbarch_register_raw_size?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2003-02-27  Daniel Jacobowitz  <drow@mvista.com>

	* dwarf2expr.c (new_dwarf_expr_context): Add (void) to definition.
	* dwarf2loc.c (dwarf_expr_read_reg): Rename regnum argument to
	dwarf_regnum.  Use gdbarch_register_raw_size.

Index: dwarf2expr.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2expr.c,v
retrieving revision 1.1
diff -u -p -r1.1 dwarf2expr.c
--- dwarf2expr.c	21 Feb 2003 15:24:17 -0000	1.1
+++ dwarf2expr.c	28 Feb 2003 01:48:13 -0000
@@ -35,7 +35,7 @@ static void execute_stack_op (struct dwa
 /* Create a new context for the expression evaluator.  */
 
 struct dwarf_expr_context *
-new_dwarf_expr_context ()
+new_dwarf_expr_context (void)
 {
   struct dwarf_expr_context *retval;
   retval = xcalloc (1, sizeof (struct dwarf_expr_context));
Index: dwarf2loc.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2loc.c,v
retrieving revision 1.1
diff -u -p -r1.1 dwarf2loc.c
--- dwarf2loc.c	21 Feb 2003 15:24:17 -0000	1.1
+++ dwarf2loc.c	28 Feb 2003 01:48:13 -0000
@@ -51,17 +51,21 @@ struct dwarf_expr_baton
    type will be returned in LVALP, and for lval_memory the register
    save address will be returned in ADDRP.  */
 static CORE_ADDR
-dwarf_expr_read_reg (void *baton, int regnum, enum lval_type *lvalp,
+dwarf_expr_read_reg (void *baton, int dwarf_regnum, enum lval_type *lvalp,
 		     CORE_ADDR *addrp)
 {
-  CORE_ADDR result;
   struct dwarf_expr_baton *debaton = (struct dwarf_expr_baton *) baton;
-  char *buf = (char *) alloca (MAX_REGISTER_RAW_SIZE);
-  int optimized, realnum;
+  CORE_ADDR result;
+  char *buf;
+  int optimized, regnum, realnum, regsize;
+
+  regnum = DWARF2_REG_TO_REGNUM (dwarf_regnum);
+  regsize = gdbarch_register_raw_size (current_gdbarch, regnum);
+  buf = (char *) alloca (regsize);
 
-  frame_register (debaton->frame, DWARF2_REG_TO_REGNUM (regnum),
-		  &optimized, lvalp, addrp, &realnum, buf);
-  result = extract_address (buf, REGISTER_RAW_SIZE (regnum));
+  frame_register (debaton->frame, regnum, &optimized, lvalp, addrp, &realnum,
+		  buf);
+  result = extract_address (buf, regsize);
 
   return result;
 }

Re: The ari hits

[Andrew Cagney]

> On Thu, Feb 27, 2003 at 05:09:46PM -0500, Andrew Cagney wrote:
> 
>> Daniel,
>> 
>> The files you recently committed trip the ARI.  Can you please check 
>> this out.
>> 
>> Andrew
>> 
>> http://sources.redhat.com/gdb/current/ari/
> 
> 
> Thanks for reminding me; this patch fixes them.  Almost obvious except
> for a bit that I want your opinion on - the hint on the ARI
> says to use register_size but I'm not convinced that's right.  Is
> gdbarch_register_size always big enough that I don't need to use
> gdbarch_register_raw_size?

You're correct, however, so is the comment - use register_size() (not 
gdbarch_register_size).  The problem is that I forgot to add that 
function to regcache.[ch] :-(  I've just done this.

There is also a bigger problem here.  Because some targets still have 
differring raw and cooked register sizes (read MIPS), things get messy.

frame_register() returns a `cooked' register value so, for the moment, 
I'd use:

	REGISTER_VIRTUAL_SIZE (...) /* OK */

(the ``/* OK */'' gags the ARI) and add a comment.

sorry about this,

Andrew

Re: The ari hits

[Daniel Jacobowitz]

On Fri, Feb 28, 2003 at 12:56:40PM -0500, Andrew Cagney wrote:
> >On Thu, Feb 27, 2003 at 05:09:46PM -0500, Andrew Cagney wrote:
> >
> >>Daniel,
> >>
> >>The files you recently committed trip the ARI.  Can you please check 
> >>this out.
> >>
> >>Andrew
> >>
> >>http://sources.redhat.com/gdb/current/ari/
> >
> >
> >Thanks for reminding me; this patch fixes them.  Almost obvious except
> >for a bit that I want your opinion on - the hint on the ARI
> >says to use register_size but I'm not convinced that's right.  Is
> >gdbarch_register_size always big enough that I don't need to use
> >gdbarch_register_raw_size?
> 
> You're correct, however, so is the comment - use register_size() (not 
> gdbarch_register_size).  The problem is that I forgot to add that 
> function to regcache.[ch] :-(  I've just done this.
> 
> There is also a bigger problem here.  Because some targets still have 
> differring raw and cooked register sizes (read MIPS), things get messy.
> 
> frame_register() returns a `cooked' register value so, for the moment, 
> I'd use:
> 
> 	REGISTER_VIRTUAL_SIZE (...) /* OK */
> 
> (the ``/* OK */'' gags the ARI) and add a comment.
> 
> sorry about this,

That makes a lot more sense now, thank you!  I just assumed you were
implying the gdbarch_ prefix.

Here's another question, though.  frame_register may return a cooked
value, but frame_saved_regs_register_unwind uses a buffer of
REGISTER_RAW_SIZE.  Is using REGISTER_VIRTUAL_SIZE in core code really
safe?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: The ari hits

[Andrew Cagney]

>> 	REGISTER_VIRTUAL_SIZE (...) /* OK */
>> 
>> (the ``/* OK */'' gags the ARI) and add a comment.
>> 
>> sorry about this,
> 
> 
> That makes a lot more sense now, thank you!  I just assumed you were
> implying the gdbarch_ prefix.
> 
> Here's another question, though.  frame_register may return a cooked
> value, but frame_saved_regs_register_unwind uses a buffer of
> REGISTER_RAW_SIZE.  Is using REGISTER_VIRTUAL_SIZE in core code really
> safe?

Hmm, no, sorry.  It's the value_of_register() value_from_register() code 
that plays with virtual_size, not frame_register() et.al.

On the bright side, this means that it can use register_size() as that, 
when given a choice, should return the raw size.

Andrew

Re: The ari hits

[Daniel Jacobowitz]

On Sat, Mar 01, 2003 at 09:03:02PM -0500, Andrew Cagney wrote:
> 
> >>	REGISTER_VIRTUAL_SIZE (...) /* OK */
> >>
> >>(the ``/* OK */'' gags the ARI) and add a comment.
> >>
> >>sorry about this,
> >
> >
> >That makes a lot more sense now, thank you!  I just assumed you were
> >implying the gdbarch_ prefix.
> >
> >Here's another question, though.  frame_register may return a cooked
> >value, but frame_saved_regs_register_unwind uses a buffer of
> >REGISTER_RAW_SIZE.  Is using REGISTER_VIRTUAL_SIZE in core code really
> >safe?
> 
> Hmm, no, sorry.  It's the value_of_register() value_from_register() code 
> that plays with virtual_size, not frame_register() et.al.
> 
> On the bright side, this means that it can use register_size() as that, 
> when given a choice, should return the raw size.

Thanks, that makes sense.  I'll fix up the patch and commit tomorrow.

By the way, in register_size():
  gdb_assert (size == REGISTER_RAW_SIZE (regnum)); /* OK */
  gdb_assert (size == REGISTER_RAW_SIZE (regnum)); /* OK */

They're both OK, but I suspect one of them is wrong anyway :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: The ari hits

[Daniel Jacobowitz]

On Sat, Mar 01, 2003 at 10:14:53PM -0500, Daniel Jacobowitz wrote:
> On Sat, Mar 01, 2003 at 09:03:02PM -0500, Andrew Cagney wrote:
> > 
> > >>	REGISTER_VIRTUAL_SIZE (...) /* OK */
> > >>
> > >>(the ``/* OK */'' gags the ARI) and add a comment.
> > >>
> > >>sorry about this,
> > >
> > >
> > >That makes a lot more sense now, thank you!  I just assumed you were
> > >implying the gdbarch_ prefix.
> > >
> > >Here's another question, though.  frame_register may return a cooked
> > >value, but frame_saved_regs_register_unwind uses a buffer of
> > >REGISTER_RAW_SIZE.  Is using REGISTER_VIRTUAL_SIZE in core code really
> > >safe?
> > 
> > Hmm, no, sorry.  It's the value_of_register() value_from_register() code 
> > that plays with virtual_size, not frame_register() et.al.
> > 
> > On the bright side, this means that it can use register_size() as that, 
> > when given a choice, should return the raw size.
> 
> Thanks, that makes sense.  I'll fix up the patch and commit tomorrow.

Here's what I checked in.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2003-03-03  Daniel Jacobowitz  <drow@mvista.com>

	* dwarf2expr.c (new_dwarf_expr_context): Add (void) to definition.
	* dwarf2loc.c: Include "regcache.h".
	(dwarf_expr_read_reg): Rename regnum argument to dwarf_regnum.  Use
	register_size.
	* Makefile.in (dwarf2loc.o): Update dependencies.

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.338
diff -u -p -r1.338 Makefile.in
--- Makefile.in	1 Mar 2003 17:03:19 -0000	1.338
+++ Makefile.in	3 Mar 2003 21:48:57 -0000
@@ -1641,7 +1641,7 @@ dwarf2expr.o: dwarf2expr.c $(defs_h) $(s
 	 $(gdbcore_h) $(dwarf2expr_h)
 dwarf2loc.o: dwarf2loc.c $(defs_h) $(ui_out_h) $(value_h) $(frame_h) \
 	$(gdbcore_h) $(target_h) $(inferior_h) $(dwarf2expr_h) \
-	$(dwarf2loc_h) $(ax_h) $(ax_gdb_h) $(gdb_string_h)
+	$(dwarf2loc_h) $(ax_h) $(ax_gdb_h) $(regcache_h) $(gdb_string_h)
 dwarf2read.o: dwarf2read.c $(defs_h) $(bfd_h) $(symtab_h) $(gdbtypes_h) \
 	$(symfile_h) $(objfiles_h) $(elf_dwarf2_h) $(buildsym_h) \
 	$(demangle_h) $(expression_h) $(filenames_h) $(macrotab_h) \
Index: dwarf2expr.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2expr.c,v
retrieving revision 1.2
diff -u -p -r1.2 dwarf2expr.c
--- dwarf2expr.c	28 Feb 2003 20:03:17 -0000	1.2
+++ dwarf2expr.c	3 Mar 2003 21:48:57 -0000
@@ -35,7 +35,7 @@ static void execute_stack_op (struct dwa
 /* Create a new context for the expression evaluator.  */
 
 struct dwarf_expr_context *
-new_dwarf_expr_context ()
+new_dwarf_expr_context (void)
 {
   struct dwarf_expr_context *retval;
   retval = xcalloc (1, sizeof (struct dwarf_expr_context));
Index: dwarf2loc.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2loc.c,v
retrieving revision 1.2
diff -u -p -r1.2 dwarf2loc.c
--- dwarf2loc.c	28 Feb 2003 20:03:18 -0000	1.2
+++ dwarf2loc.c	3 Mar 2003 21:48:57 -0000
@@ -28,6 +28,7 @@
 #include "inferior.h"
 #include "ax.h"
 #include "ax-gdb.h"
+#include "regcache.h"
 
 #include "elf/dwarf2.h"
 #include "dwarf2expr.h"
@@ -53,17 +54,21 @@ struct dwarf_expr_baton
    type will be returned in LVALP, and for lval_memory the register
    save address will be returned in ADDRP.  */
 static CORE_ADDR
-dwarf_expr_read_reg (void *baton, int regnum, enum lval_type *lvalp,
+dwarf_expr_read_reg (void *baton, int dwarf_regnum, enum lval_type *lvalp,
 		     CORE_ADDR *addrp)
 {
-  CORE_ADDR result;
   struct dwarf_expr_baton *debaton = (struct dwarf_expr_baton *) baton;
-  char *buf = (char *) alloca (MAX_REGISTER_RAW_SIZE);
-  int optimized, realnum;
+  CORE_ADDR result;
+  char *buf;
+  int optimized, regnum, realnum, regsize;
 
-  frame_register (debaton->frame, DWARF2_REG_TO_REGNUM (regnum),
-		  &optimized, lvalp, addrp, &realnum, buf);
-  result = extract_address (buf, REGISTER_RAW_SIZE (regnum));
+  regnum = DWARF2_REG_TO_REGNUM (dwarf_regnum);
+  regsize = register_size (current_gdbarch, regnum);
+  buf = (char *) alloca (regsize);
+
+  frame_register (debaton->frame, regnum, &optimized, lvalp, addrp, &realnum,
+		  buf);
+  result = extract_address (buf, regsize);
 
   return result;
 }

The ARI hits

[Andrew Cagney]

Dave, Michael,

The ARI's chucked an 8.3 wobley over the FRV sim tests that were 
recently added.

enjoy,
Andrew

http://sources.redhat.com/gdb/current/ari/