Re: [RFA]: Symbol evaluation code

[Daniel Berlin <dan@cgsoftware.com>]

Andrew Cagney <ac131313@cygnus.com> writes:

>> I plan on making the push_opcode non-varargs before making anything
>> use it, but i really want to get this stuff out of my tree and into
>> sourceware, before I start having fun with cvs conflicts.  Also, one
>> of my HD's is starting to go, and I didn't want to lose it.
> 
> 
> (Jim B actually suggested this)
> 
> Just FYI, if people are creating a lot of expermental code then it
> might be a good idea to keep them on a CVS branch rather than in a
> local sandpit.  At least that way it is being backed up and it is
> available for others to view.
Well, I plan on doing this for the type work soon.
Where soon is later today.  I want to submit the dwarf2 rewrite so far
for comments, first.

However, the symbol evaluation code is, as I said somewhere,
completely self contained. Nothing uses it, it has no dependencies on
anything except itself, etc.

So what's the rule for things like that?
It doesn't seem to make sense to create a branch for it, it's not
affecting any other part of gdb, so you end up having to just do
merges for no good reason.
Moving to using it can be done completely incrementally, without any
hacks or disabling of anything.  
It would seem, if we all agree this is the general direction to go in,
that things like that should just be added to the main branch.

I ask because, I actually made push_opcodes non-varargs.  There are 3 push_operand
routines now, one for each type. They each take a cookie push_opcodes
returns, so we can do the same format checking and type checking
push_opcodes did.
So it's ready to be submitted, unless you want me to put it on a branch.

> 
> 
> I should note though, that there is a big difference between using a
> branch to run a few experements and using a branch to create jumbo
> patches.  To give an example, I'm tinkering the MI code.  Consequently
> I've the following working directories.
> 
> 
> 	MI/src
> 		I'm using this to figure out
> 		what needs changing and how
> 
> 	GDB/*	A reference directory
> 
> 	WIP/*	one of my merge directories
> 
> I'm pulling changes out of the MI directory and them merging them into
> WIP before posting them.  They then get back merged in to MI.  Over
> time MI and WIP/GDB converge.  I would never submit a patch taken
> directly from my experemental MI directory since it just isn't up to
> scratch.

> 
> 	Andrew
> 
> 
> 

-- 
"I like to skate on the other side of the ice.
"-Steven Wright