Re: Merging OC gdb with official gdb

[Andrew Cagney <ac131313@ges.redhat.com>]

> Andrew,
> 
> 
>> The current documentation is being updated (slowly).  Also see the thread:
>>
>> http://sources.redhat.com/ml/gdb/2002-07/msg00202.html
>>
>> but unless your architecture is really wierd, nothing should be needed.
> 
> no, it is very similar to PPC, it is very clean RISC implementation.

Good!

>> - getting it to strictly use the multi-arch framework (the exception
>> being if your platform has shared libraries)
> 
> 
> I don't quite understand what you mean with "if your platform has shared 
> libraries", can you rephrase please.

Ever since 5.0, GDB has only been accepting new multi-arch targets. 
Ever since 5.1, GDB has only beeing accepting extensions to an existing 
architecture when the base architecture has been multi-arched.

If a target system doesn't have shared libraries then it will be pure 
multi-arch (no config/CPU/tm-CPU.h file).  See xstormy16.

If the target system does have shared libraries then it will be almost 
pure multi-arch (a very small config/CPU/tm-CPU.h).  See cris.

> I saw multi-arch framework would require a lot of work for our target, it 
> would be nice if we could make it without it.

Getting something converted to multi-arch is mechanical.  See:
http://sources.redhat.com/gdb/current/onlinedocs/gdbint_9.html#SEC78
for the recommended process.

> We have following deprecated macros:
> #define EXTRACT_RETURN_VALUE(TYPE, REGBUF, VALBUF)
> #define STORE_RETURN_VALUE(TYPE,VALBUF)
> #define EXTRACT_STRUCT_VALUE_ADDRESS(REGBUF)
> Is it possible to solve them without multi-arch?

Not really.  GDB is a moving target.  The above macro's, for instance, 
have been replaced with better equivalents.  An ongoing task is to 
eliminate all existing references.  I don't think it is reasonable to 
prolong this task by adding still more references.

Remember, once you've brought this architecture up to current standards 
and it has been accepted into GDB, the GDB developers take on a 
significant part of its ongoing maintenance.  All GDB developers are, 
for instance, expected to ensure that this new target architecture builds.

>> - getting it to comply to gnu (and GDB) coding standards
> 
> of course.

You should also look through the ``Fixed'' entries listed at the bottom 
of:  http://sources.redhat.com/gdb/current/ari/

>> - FSF paperwork
> 
> already have it.

Good!

>> Otherwize it should drop in.  Take a look at one of the very recent
>> targets (xstormy16?).
> 
> ok.
> 
> thanks for your help,
> Marko

Andrew