Re: [patch] Add start of mips32/mips64 support to sim/mips/mips.igen

Re: [patch] Add start of mips32/mips64 support to sim/mips/mips.igen

[Andrew Cagney]

"Chris G. Demetriou" wrote:

[there was an interveening e-mail]

> Andrew Cagney <ac131313@cygnus.com> writes:
> > Two quick questions first off.
> >
> >       o       what is mipsV?

Sorry, what I ment to say was that the change adds ``mipsV'' yet nothing
else explains this.  If nothing else it is most likely a separate
change.

	Andrew
From ac131313@cygnus.com Mon Dec 04 16:33:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Chris G. Demetriou" <cgd@sibyte.com>, gdb-patches@sources.redhat.com
Subject: Re: [patch] Add start of mips32/mips64 support to sim/mips/mips.igen
Date: Mon, 04 Dec 2000 16:33:00 -0000
Message-id: <3A2C35A7.A018EBEE@cygnus.com>
References: <5telznaixe.fsf@highland.sibyte.com> <3A2C2415.5709A40@cygnus.com>
X-SW-Source: 2000-12/msg00097.html
Content-length: 870

Andrew Cagney wrote:

>         o       is there documentation for mips32/mips64
>                 publically available so that I check
>                 your changes against it?

To expand on this one.  I've two concerns.

	o	I'd like to see a patch tabled
		that adds the full mips32/mips64 ISA.

		I think a new ISA should be added
		as a single patch and not as an
		incremental set of changes.

	o	I'd like to be sure that the information
		being committed is, one way, or another
		public.

		Instruction set simulators include a semantic
		specification of each instruction.  I'd
		like to be sure that your allowed to publish/
		submit this for the ISS.		

If there is published documentation that you can refer people to then
things are pretty easy.  If there isn't then I'll work on the assumption
that you've gone through due process on this.

enjoy,
	Andrew
From ac131313@cygnus.com Mon Dec 04 16:55:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Orjan Friberg <orjan.friberg@axis.com>
Cc: gdb-patches@sources.redhat.com, Jim Blandy <jimb@cygnus.com>
Subject: Re: New port: CRIS architecture
Date: Mon, 04 Dec 2000 16:55:00 -0000
Message-id: <3A2C3AC7.9F7F454F@cygnus.com>
References: <3A2BAEF0.A4641A0C@axis.com>
X-SW-Source: 2000-12/msg00098.html
Content-length: 678

FYI,

I can't find an assignment in place?

Several more generic comments.

tm-cris.h:
	I'm trying to figure out why it is needed.
	The obvious problem is SOFTWARE_SINGLESTEP_P.
	I'll fix that.

	Beyond that one, what else is needed?  I'd
	like to see a second pure multi-arch target
	in GDB so will help where needed.

cris-tdep.c:
	It is preferable to have enums and
	two line functions rather than macros.
	They both make the long term job of
	maintenance far easier.

	Other files have put __initialize*
	and xxx_arch_init() at the end.  I'd
	just suggest moving them.

	Other than that, absolutly nothing
	has jumped up and even the above
	are not problems.

cool!
	Andrew
From cgd@sibyte.com Mon Dec 04 17:25:00 2000
From: cgd@sibyte.com (Chris G. Demetriou)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] Add start of mips32/mips64 support to sim/mips/mips.igen
Date: Mon, 04 Dec 2000 17:25:00 -0000
Message-id: <5t8zpvacdl.fsf@highland.sibyte.com>
References: <5telznaixe.fsf@highland.sibyte.com> <3A2C2415.5709A40@cygnus.com> <3A2C35A7.A018EBEE@cygnus.com>
X-SW-Source: 2000-12/msg00099.html
Content-length: 2032

[ To reply to two messages in one ]

> To expand on this one.  I've two concerns.
> 
> 	o	I'd like to see a patch tabled
> 		that adds the full mips32/mips64 ISA.
> 
> 		I think a new ISA should be added
> 		as a single patch and not as an
> 		incremental set of changes.

OK.  Having worked in the other tools, my inclination was stepwise
refinement.

We can certainly do this if you are so inclined.  Would you prefer:

(a) 1 patch which adds MIPS V, MIPS32, and MIPS64 at once, or

(b) 1 patch for each.

I think if the goal is to do "one patch that just does it," I'd prefer
the former, because it means a lot less duplication of effort.


> 	o	I'd like to be sure that the information
> 		being committed is, one way, or another
> 		public.
> 
> 		Instruction set simulators include a semantic
> 		specification of each instruction.  I'd
> 		like to be sure that your allowed to publish/
> 		submit this for the ISS.		
> 
> If there is published documentation that you can refer people to then
> things are pretty easy.  If there isn't then I'll work on the assumption
> that you've gone through due process on this.

There is some public documentation on MIPS32, as part of the MIPS32 4K
core documentation available on:

	http://www.mips.com/publications/index.html

For the rest, yes, we've done the due process.  8-)


> "Chris G. Demetriou" wrote:
> [there was an interveening e-mail]
>
> > Andrew Cagney <ac131313@cygnus.com> writes:
> > > Two quick questions first off.
> > >
> > >       o       what is mipsV?
>
> Sorry, what I ment to say was that the change adds ``mipsV'' yet nothing
> else explains this.  If nothing else it is most likely a separate change.

Oh, I'm sorry.  I thought i'd mentioned it in my ChangLog, along with
the mips32 and mips64 entries, but I guess I didn't.

It's another ISA, like MIPS I - MIPS IV.  (It incorporates all of MIPS
IV and adds on to it.)  If i recall correctly, its main addition is
Paired Single floating point operations, but it's been a while since
I've checked.



chris
From hans-peter.nilsson@axis.com Mon Dec 04 17:57:00 2000
From: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
To: ac131313@cygnus.com
Cc: orjan.friberg@axis.com, gdb-patches@sources.redhat.com, jimb@cygnus.com
Subject: Re: New port: CRIS architecture
Date: Mon, 04 Dec 2000 17:57:00 -0000
Message-id: <200012050156.CAA03951@ignucius.axis.se>
References: <3A2C3AC7.9F7F454F@cygnus.com>
X-SW-Source: 2000-12/msg00100.html
Content-length: 323

> Date: Tue, 05 Dec 2000 11:45:59 +1100
> From: Andrew Cagney <ac131313@cygnus.com>

> I can't find an assignment in place?

There is a multi- assign.future a'la Wind River and former
Cygnus in place since October 1998 for all Axis Communications
employees, listing GDB as one item.  Suggest search for "Axis".

brgds, H-P
From dje@transmeta.com Mon Dec 04 18:40:00 2000
From: Doug Evans <dje@transmeta.com>
To: Ben Elliston <bje@redhat.com>
Cc: <gdb-patches@sources.redhat.com>, <cgen@sources.redhat.com>
Subject: Re: [Sim] New sim/common/cgen.sh
Date: Mon, 04 Dec 2000 18:40:00 -0000
Message-id: <14892.21907.916077.737133@casey.transmeta.com>
References: <14891.59510.53616.923378@casey.transmeta.com> <Pine.LNX.4.30.0012050810410.5910-100000@moshpit.cygnus.com>
X-SW-Source: 2000-12/msg00101.html
Content-length: 601

Ben Elliston writes:
 >     > I have also just fixed genmloop.sh so that it has an -outfile-suffix option.
 >     > This allows the generated files to form unique filenames -- so it, too, can
 >     > be run by a parallel make.
 > 
 >    Can't this problem be solved without adding an option?
 > 
 > Can you suggest how?

The theory is that the script is already being passed something it can use.

There's the -cpu argument.  I dunno if your @prefix@ patches change whether
genmloop.sh should use @cpu@ or @prefix@, but won't one of them
(whichever it is) be sufficient to separate the output files?
From msnyder@cygnus.com Mon Dec 04 19:15:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: [PATCH] Fix typo in error msg.
Date: Mon, 04 Dec 2000 19:15:00 -0000
Message-id: <200012050315.TAA01235@cleaver.cygnus.com>
X-SW-Source: 2000-12/msg00102.html
Content-length: 1248

In internal_verror, the error message has the word "make" twice.

2000-12-04  Michael Snyder  <msnyder@cleaver.cygnus.com>

        * utils.c (internal_verror): Fix typo in error msg.

Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.23
diff -c -3 -p -r1.23 utils.c
*** utils.c	2000/11/20 02:06:19	1.23
--- utils.c	2000/12/05 03:14:31
*************** internal_verror (const char *fmt, va_lis
*** 699,705 ****
    /* Default (no case) is to quit GDB.  When in batch mode this
       lessens the likelhood of GDB going into an infinate loop. */
    continue_p = query ("\
! An internal GDB error was detected.  This may make make further\n\
  debugging unreliable.  Continue this debugging session? ");
  
    /* Default (no case) is to not dump core.  Lessen the chance of GDB
--- 699,705 ----
    /* Default (no case) is to quit GDB.  When in batch mode this
       lessens the likelhood of GDB going into an infinate loop. */
    continue_p = query ("\
! An internal GDB error was detected.  This may make further\n\
  debugging unreliable.  Continue this debugging session? ");
  
    /* Default (no case) is to not dump core.  Lessen the chance of GDB
From bje@redhat.com Mon Dec 04 19:29:00 2000
From: Ben Elliston <bje@redhat.com>
To: Doug Evans <dje@transmeta.com>
Cc: <gdb-patches@sources.redhat.com>, <cgen@sources.redhat.com>
Subject: Re: [Sim] New sim/common/cgen.sh
Date: Mon, 04 Dec 2000 19:29:00 -0000
Message-id: <Pine.LNX.4.30.0012051428270.7250-100000@moshpit.cygnus.com>
References: <14892.21907.916077.737133@casey.transmeta.com>
X-SW-Source: 2000-12/msg00103.html
Content-length: 368

   The theory is that the script is already being passed something it can
   use.

The same could be said for determining the input filename (ie. mloop.in),
but we provide the flexibility to specify *that*.  There is even a comment
in genmloop.sh that says that it would be useful to provide options to
specify the output filenames (both of them) in the future.

Ben

Re: [patch] Add start of mips32/mips64 support to sim/mips/mips.igen

[Chris G. Demetriou]

Andrew Cagney <ac131313@cygnus.com> writes:
> [Ah, summer and holidays...]

And for me, the holidays and the acquisition.  8-)

As noted elsewhere (and to the FSF assignment folks), I'm in currently
in an interesting situation w.r.t. my assignment paperwork.  In a
nutshell I need to get the employer disclaimer done before i submit
any more non-trivial changes.  (However, the existing submissions
should be OK, as should any obvious bug fixes to them that are
necessary.)

I'm working on resolving this, obviously.


> Chris,  could you please add yourself and my self to sim/MAINTAINERS as
> mips sim maintainers.

Yes, sure, i'll do that in a bit.

(Obviously, regardless of my current assignment status, I can read and
comment on others' MIPS-related patches.  8-)


> I'll next go through each of the patches (but
> they should be ok).  Once the backlog is cleared, we can probably start
> using a much simpler self-approval process.

Actually, if you'd please hold off on that, I'd appreciate it.

When I did the original patches, I didn't check any mips16 variants,
and some subsequent testing on my end showed a few problems there.

I'd like to get them sorted through before any of the changes goes in.


thanks,

chris
From ac131313@cygnus.com Fri Jan 12 18:10:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Snyder <msnyder@redhat.com>
Cc: Nicholas Duffek <nsd@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] gdbarch.sh: document REGISTER_SIZE and REGISTER_BYTES
Date: Fri, 12 Jan 2001 18:10:00 -0000
Message-id: <3A5FB7E6.699D6C07@cygnus.com>
References: <200101032041.PAA14834@nog.bosbc.com> <3A5EF4D0.C838379@cygnus.com> <3A5F46B6.216D@redhat.com>
X-SW-Source: 2001-01/msg00101.html
Content-length: 944

Michael Snyder wrote:
> 
> Andrew Cagney wrote:
> 
> > Given that pseudo-register values are created using a fuction and raw
> > register data, do they have any storage?
> 
> Sometimes yes, sometimes no.  A pseudo-register can be just
> an alias for another register, in which case it can share
> storage.  But it can also be a computed value, in which case
> it may have its own storage.  I had one case in which a
> pseudo-register was the concatenation of two regular
> registers -- but they weren't consecutive, so I had to
> give the pseudo its own storage and copy them.

As far as I can tell, in all these cases that pseudo register could have
been implemented as a functon.  The only reason I can think of for
having to allocate storage is to work around warts in the way registers
are currently implemented.  If the core of GDB only accessed registers
using read/write methods then the storage problem could go away.

	enjoy,
		Andrew
From ac131313@cygnus.com Fri Jan 12 18:15:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New register definition interface
Date: Fri, 12 Jan 2001 18:15:00 -0000
Message-id: <3A5FB8E3.8E778C41@cygnus.com>
References: <3A5F09B3.93555F06@cygnus.com> <200101122144.f0CLi0104421@rtl.cygnus.com>
X-SW-Source: 2001-01/msg00102.html
Content-length: 568

Nick Duffek wrote:
> 
> On 12-Jan-2001, Andrew Cagney wrote:
> 
> >At a guess the cli/* change is independant of the file reg.c.
> 
> It depends on regs.c, but not vice versa.  So yes, it could have been a
> separate add-on patch.

I'm confused.  Your saying that the CLI changes depend on regs.c?  I
think that is wrong.  It should be possible to code the cli so that it
doesn't specificly depend on regs.c.  Rather it depends on some abstract
interface.  It might be implemented using regs.c but it might also be
implemented using more traditional methods.

	Andrew
From ac131313@cygnus.com Fri Jan 12 18:19:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] gdbarch.sh: multi-arch PARM_BOUNDARY
Date: Fri, 12 Jan 2001 18:19:00 -0000
Message-id: <3A5FB9DC.13C882CF@cygnus.com>
References: <3A5EF5A4.7C7EF047@cygnus.com> <200101122055.f0CKtkD04372@rtl.cygnus.com>
X-SW-Source: 2001-01/msg00103.html
Content-length: 343

Nick Duffek wrote:
> 
> On 12-Jan-2001, Andrew Cagney wrote:
> 
> >This is a new architecture method.
> 
> No, it's an existing method, I'm just multi-arching it.

Hmm, cut/paste re-grep.  Sorry, yes.  I was searching for PARAM_BOUNDARY
(and I can't spell :-)
You don't need approval, just post and then give it a few days to
settle.

	Andrew
From jingham@apple.com Fri Jan 12 19:04:00 2001
From: Jim Ingham <jingham@apple.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Fri, 12 Jan 2001 19:04:00 -0000
Message-id: <200101130303.TAA05813@scv3.apple.com>
References: <Pine.LNX.4.31.0101122049230.14785-100000@www.cgsoftware.com>
X-SW-Source: 2001-01/msg00104.html
Content-length: 2475

Daniel,

I am not ragging on you specifically, but it is very very lame (almost 
warranting the epithet "egregiously heinous") that a crashing bug has 
sat around in the gdb sources for three months or so - with a KNOWN 
fix!  Particularly one that is triggered by simple actions like trying 
to print instance data in only moderately complicated C++ objects.

I understand that there is some argument over whether the current 
implementation of C++ symbol lookup is the right one, but while it is in 
place, simple fixes to it need to get into the sources quickly.  It is 
not sufficient to say that the crash was reported in this forum - 
Fernando didn't make the connection either, and he is no slouch to say 
the least...  And most gdb users don't read gdb patches.

Just like no user error, no matter how stupid, should ever result in a 
crash, no patch that keeps gdb from crashing should be refused unless 
the maintainer can come up with another solution quickly.  It is one 
thing if gdb doesn't find a symbol, or reports some data wrong.  That is 
bad, but there is leisure to argue over method, since users can 
generally work around it and still get their job done.  If gdb crashes - 
particularly on a common code path, then users are just stuck...

If it is really the case that this patch is waiting on Jim's approval, 
do we need to have a "fast track crash prevention approval mechanism" in 
the Maintainer system for gdb?

This sort of thing makes gdb look really bad.

Jim

On Friday, January 12, 2001, at 05:52 PM, Daniel Berlin wrote:

>
>
> On Fri, 12 Jan 2001, Jim Ingham wrote:
>
>> Daniel,
>>
>> Well, while you are waiting, it might be nice to check in fixes for 
>> some
>> of these, since they are pretty simple fixes, and the bugs are pretty
>> annoying (in this case it causes gdb to crash, and people tend to 
>> REALLY
>> hate it when their debugger crashes).
>
> I can't without approval from Jim anyway. I'm still waiting for approval
> for some simple changes I submitted a few weeks ago to be approved as
> well, i don't want to juggle that many outstanding patches.
>
>> It wasted a couple of days of my
>> time chasing it down, and apparently a couple of days of Fernando's 
>> time
>> as well.
> Sorry to hear that. If you look back, ti was reported in either november
> or december, and a huge discussion ensued.
> Wish there was something more I could do, but it's not my area of
> maintenance, so all I can do is submit patches.
>
>
From dberlin@redhat.com Fri Jan 12 20:43:00 2001
From: Daniel Berlin <dberlin@redhat.com>
To: Jim Ingham <jingham@apple.com>
Cc: Daniel Berlin <dberlin@redhat.com>, <gdb-patches@sources.redhat.com>
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Fri, 12 Jan 2001 20:43:00 -0000
Message-id: <Pine.LNX.4.31.0101122216180.15353-100000@www.cgsoftware.com>
References: <200101130303.TAA05813@scv3.apple.com>
X-SW-Source: 2001-01/msg00105.html
Content-length: 4018

On Fri, 12 Jan 2001, Jim Ingham wrote:

> Daniel,
>
> I am not ragging on you specifically, but it is very very lame (almost
> warranting the epithet "egregiously heinous") that a crashing bug has
> sat around in the gdb sources for three months or so - with a KNOWN
> fix!

Yup.
I agree completely.
I take full responsibility for the bug itself, since it was my code that
did it, but it's not something that wasn't noticed, and didn't have a fix.


> Particularly one that is triggered by simple actions  like trying
> to print instance data in only moderately complicated C++ objects.
>

> I understand that there is some argument over whether the current
> implementation of C++ symbol lookup is the right one, but while it is in
> place, simple fixes to it need to get into the sources quickly.

I'd happily check them in under an obvious bugfix rule, but I don't want
to step on any toes.
I had enough fun doing that trying to figure out what exact areas of code
C++ maintainer covers, and I still couldn't tell you.
If someone with definite maintainership over the symbol tables says I can
check in the fixes, i'll do it. Otherwise, i won't.
Sorry.


> It is
> not sufficient to say that the crash was reported in this forum -
> Fernando didn't make the connection either, and he is no slouch to say
> the least...

Err, i'm curious, if you noticed a problem with crashes trying to print
C++ objects, why didn't you ask me or Jim, as i'm C++ maintainer, and he's
symbol table maintainer.

>  And most gdb users don't read gdb patches. Sure,
i'll give you that.

>
> Just like no user error, no matter how stupid, should ever result in a
> crash, no patch that keeps gdb from crashing should be refused unless
> the maintainer can come up with another solution quickly.  It is one
> thing if gdb doesn't find a symbol, or reports some data wrong.  That is
> bad, but there is leisure to argue over method, since users can
> generally work around it and still get their job done.  If gdb crashes -
> particularly on a common code path, then users are just stuck...
If they use CVS versions, yes.

>
> If it is really the case that this patch is waiting on Jim's approval,
> do we need to have a "fast track crash prevention approval mechanism" in
> the Maintainer system for gdb?
We do, it's the obvious bugfix rule, but it's hard to say what is
obvious to everyone.
I don't feel comfortable making that call right now, I'm pretty tired of
taking the backlash from the people who think it isn't obvious/needed
approval which invariably happens.

As I said, isn't the only patch i've got outstanding, and most of them are
trivial
fixes/improvements, because I've not yet submitted some large improvements
made to memory usage/demangling speed/symbol lookup speed for C++/every
language except C/infrastructure improvements for C++/dwarf2 improvements.
Among other improvements. Normally, I would just keep pinging Jim until I
get a response, but to be honest, all the politicking and crap that
has happened with regards to the steering committee, etc, has
kinda demotivated me, and it's hard to motivate myself to contribute to
gdb outside of work, either large or small improvements.
I'm sure it'll pass in a month or so.
 >
> This sort of thing makes gdb look really bad.
Yeah, but it's only in gdb CVS, don't forget.
I get the feeling you guys are shipping CVS gdb's to people.
Well, it's not just a feeling, I have a powerbook with OS X 4F8 (acquired
through a lot of pain and trouble) on it, and
I just looked, and it's  GDB 20000912, a CVS version.

Which explains why you keep mentioning users, when the bug only exists in
CVS.
This is a very bad idea to be doing.
However, if you like, I'll happily make sure C++ nicely, if I didn't have
to go through a ton of  pain to get new builds so I could check it out (IE
I was seeded the same as the other developers who got 4F8 and friends the
normal way)
I know it's in Darwin CVS, but I can't make that compile without the right
versions of OS X anyway.

--Dan