Jim Ingham | 1 Oct 02:48 2002
Picon

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

Hi, all...

The changes from mi0 to mi1 were pretty trivial.  So clients (in my 
case Project Builder) can fairly easily accommodate the removal of the 
mi0 interpreter.  I am not suggesting that we reinstate that.

However, the mi2 is shaping up to be a pretty big change (among other 
things, command results are differently reported in toto, as well as 
some command results changing format.)  Converting PB from mi1 to mi2 
is going to be a lot of work.   And because of its nature, there is no 
a priori way to tell what all the clients are - and not all the clients 
will closely read the gdb-patches mailing list...

Because of this, I am a little nervous at the easy way we are talking 
about deleting older versions of the mi.  I think it is our 
responsibility to careful, and only release versions of the mi that we 
want to support, not the clients of the mi's responsibility to change 
their code every time we decide we are tired of supporting the test 
cases from one of the other versions we have previously promulgated...  
The mi loses much of its appeal if it means you are going to have to 
occasionally rework parts of your client that already work just fine, 
or suffer permanent fork-hood for your gdb.

I agree with Daniel that we should hold off on declaring a real mi2 
till we have something we are willing to support long term.   And for 
the mi to be useful, I think we need to stick to only putting out named 
versions that we are willing to support.

Jim

(Continue reading)

Andrew Cagney | 1 Oct 03:07 2002
Picon

Re: Patch for gdb/mi problem 672

> For the testsuite: mi0 is no more. These modified tests should go in
> as mi2-var-child.exp, etc, leaving the mi-var... unchanged. Is this
> the intent? Andrew?

Other way round.

mi-var-child.exp gets the updates (it uses -i=mi) but mi1-var-child.exp 
is frozen.

It will mean changing:

> -      ui_out_tuple_begin (uiout, "changelist");
> +      ui_out_list_begin (uiout, "changelist");

to:
	if(mi_version (uiout) <= 1)
	  ui_out_tuple_begin (uiout, "changelist");
	else
	  ui_out_list_begin (uiout, "changelist");
(ulgh!) (or similar).  (perhaphs mi_version_p (uiout, 1) would have been 
a better interface.  Too late :-)

The output is broken but its been broken since GDB 5.0 so I think this 
is a mi1->mi2 syntax change.

Andrew

Andrew Cagney | 1 Oct 03:24 2002
Picon

Re: [rfc] Only compare against dummy frame's top when explicitly set

> 2002-09-25  Andrew Cagney  <ac131313 <at> redhat.com>
> 
> 	* blockframe.c (generic_find_dummy_frame): Rewrite.  Only test
> 	against TOP when TOP was explictly set.
> 	(generic_push_dummy_frame): Set TOP to zero.
> 
I've checked this in.

If backtraces, for your target suddenly break, this is the patch to look at.

Andrew

Andrew Cagney | 1 Oct 03:32 2002
Picon

[patch/mips} Convert MIPS to generic dummy frames

FYI,

I've committed the attached.  The MIPS now uses generic dumy frames.

Andrew
2002-09-30  Andrew Cagney  <ac131313 <at> redhat.com>

	* mips-tdep.c (mips_frame_saved_pc): When a generic dummy frame,
	use frame_unwind_signed_register to obtain the PC.
	(mips_frame_chain): Handle a generic dummy frame.
	(mips_init_extra_frame_info): When a generic dummy frame, don't
	re-compute the frame base.
	(mips_pop_frame): Handle generic dummy frames.
	(mips_gdbarch_init): When generic dummy frames, set
	use_generic_dummy_frames, push_dummy_frame to
	generic_push_dummy_frame, pc_in_call_dummy to
	generic_pc_in_call_dummy, and save_dummy_frame_top_of_stack to
	generic_save_dummy_frame_tos.

Index: mips-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/mips-tdep.c,v
retrieving revision 1.127
diff -u -r1.127 mips-tdep.c
--- mips-tdep.c	27 Sep 2002 00:49:01 -0000	1.127
+++ mips-tdep.c	1 Oct 2002 01:28:37 -0000
 <at>  <at>  -1704,7 +1704,14  <at>  <at> 
   int pcreg = frame->signal_handler_caller ? PC_REGNUM
(Continue reading)

Aidan Skinner | 1 Oct 05:17 2002
Picon

Re: [RFA] Add type support for Ada

On Sat, Sep 28, 2002 at 02:25:59AM -0700, Paul N. Hilfinger wrote

Thanks for answering these Paul. :)

> > It looks to me as if the string cleanup stuff is distinct from the
> > fixed instance stuff.  These should be submitted as separate patches.
> 
> They definitely are logically separate changes.

Yeah, I'll split and resubmit and probably take the opportunity to
include some more string cleanup stuff, rather than just the bits that
ada-* reference...

> > Should base_type use the tortoise-and-hare algorithm to detect cycles?
> 
> An interesting suggestion.  However, there is at least one existing
> place where GDB doesn't bother.  Compare with the following (non-Ada-

I think it's worthwhile doing here, and if it works nicely it can be
stolen for other places. My next revision of this patch will include
this.

> Umm. Interesting questions.  As I recall, I had the impression that 
> a self-referencing range type COULD occur legitimately, but given that was

I think they can, but my current understanding of the gdb type system
probably bears some resemblence to swiss cheese. ;)

I'll experiment a bit with trying to create one and see what I can find.

(Continue reading)

Eli Zaretskii | 1 Oct 06:51 2002
Picon

Re: [rfa:breakpoint] Correctly count watchpoints


On Mon, 30 Sep 2002, Andrew Cagney wrote:

> On the i386, one watch resource is two registers.

Why two?  Some expressions might need 3 registers.  If you use this 
worst-case scenario, GDB will think it cannot watch more than a single 
expression, and that some data types, such as double's, and complex 
aggregates, such as struct's, cannot be watched at all.  It's hardly a 
Good Thing to refuse to set watchpoints based on inaccurate decisions 
like this.

> > But this is very hard or even impossible to do in practice.  For
> > example, on a i386, if there are two watchpoint that watch the same
> > 4-byte aligned int variable, you need only one debug register to watch
> > them both, so counting each one as taking one resource is incorrect.
> 
> That is a bug.  A further change would be to accumulate all the regions 
> and eliminate any overlap from the count.

This requires a significant change in the high-level code of GDB: it 
needs to pass all the information about all the ``active'' watchpoints to 
the function that tells how many watchpoint resources are required for 
the next watchpoint.

> For an architecture to try and optimally allocate watchpoint resources, 
> I don't think (cf opencore code) a list of ADDR:LEN pairs is sufficient. 
>   Instead it should be provided with all the watchpoint expressions.

So that means an architecture should know about GDB's expression-parsing 
(Continue reading)

Eli Zaretskii | 1 Oct 07:10 2002
Picon

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0


On Mon, 30 Sep 2002, Andrew Cagney wrote:

> > Yes, but perhaps the manual should also say that mi0 is no longer 
> > supported.
> 
> Now is:
> 
>  <at> samp{--interpreter=mi} (or  <at> samp{--interpreter=mi2}) causes
>  <at> value{GDBN} to use the current  <at> dfn{ <at> sc{gdb/mi} interface}
> ( <at> pxref{GDB/MI, , The  <at> sc{gdb/mi} Interface}).  The previous  <at> sc{gdb/mi}
> interface, included in  <at> value{GDBN} version 5.3, can be selected with
>  <at> samp{--interpreter=mi1}.  Earlier  <at> sc{gdb/mi} interfaces
> are not supported.

Fine, thanks.

Andrew Cagney | 1 Oct 07:30 2002
Picon

[rfa:ppc+5.3] Fix "vrsave" regnum

Hello,

The attached fixes the number of the vrsave register (for the 
powerpc:7400 variant).  Without the patch, ``info vector'' gets an 
internal error - 153 >= NUM_REGS+NUM_PSEUDO_REGS==153.

Ok?  HEAD and 5.3 branch?

Andrew
2002-10-01  Andrew Cagney  <ac131313 <at> redhat.com>

	* rs6000-tdep.c (rs6000_gdbarch_init): For powerpc:7400, fix
	"vrsave"'s register number.

Index: rs6000-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v
retrieving revision 1.85
diff -u -r1.85 rs6000-tdep.c
--- rs6000-tdep.c	26 Sep 2002 22:34:07 -0000	1.85
+++ rs6000-tdep.c	1 Oct 2002 05:26:27 -0000
 <at>  <at>  -2793,7 +2793,7  <at>  <at> 
 	break;
       case bfd_mach_ppc_7400:
 	tdep->ppc_vr0_regnum = 119;
-	tdep->ppc_vrsave_regnum = 153;
+	tdep->ppc_vrsave_regnum = 152;
 	tdep->ppc_ev0_regnum = -1;
(Continue reading)

Andrew Cagney | 1 Oct 07:59 2002
Picon

Re: [rfa:breakpoint] Correctly count watchpoints

> On Mon, 30 Sep 2002, Andrew Cagney wrote:
> 
> 
>> On the i386, one watch resource is two registers.
> 
> 
> Why two?  Some expressions might need 3 registers.  If you use this 
> worst-case scenario, GDB will think it cannot watch more than a single 
> expression, and that some data types, such as double's, and complex 
> aggregates, such as struct's, cannot be watched at all.  It's hardly a 
> Good Thing to refuse to set watchpoints based on inaccurate decisions 
> like this.

You mentioned two :-)

Under the current arangement, an architecture has two choices:

- have target_can_use_hardware_watchpoints() always return true (most 
targets appear to do this) and then error while trying to insert the 
watchpoints.  This is what the i386 currently does.

- have target_can_use...() make use of the counts and return an 
indication based on that

>> > But this is very hard or even impossible to do in practice.  For
>> > example, on a i386, if there are two watchpoint that watch the same
>> > 4-byte aligned int variable, you need only one debug register to watch
>> > them both, so counting each one as taking one resource is incorrect.
> 
>> 
(Continue reading)

Kevin Buettner | 1 Oct 08:34 2002
Picon

Re: [rfa:ppc+5.3] Fix "vrsave" regnum

On Oct 1,  1:30am, Andrew Cagney wrote:

> The attached fixes the number of the vrsave register (for the 
> powerpc:7400 variant).  Without the patch, ``info vector'' gets an 
> internal error - 153 >= NUM_REGS+NUM_PSEUDO_REGS==153.
> 
> Ok?  HEAD and 5.3 branch?

Yes, to both.

Thanks,

Kevin


Gmane