Merging OC gdb with official gdb

Merging OC gdb with official gdb

[Marko Mlinar]

Hi!

At opencores (www.opencores.org) we have a gdb-5.0 port to our or1k 
architecture.
We would like to join our sources into official version.
Your current BFD already has needed or32 support.
I have seen, that gdb went thought many internal changes, like regcache, etc.

I've looked at documentation, and it is outdated. Although there are promising 
mails, like below one ;), there is not enough info for me to break through.

------------
From: Andrew Cagney <ac131313@cygnus.com>
To: Richard.Earnshaw@arm.com
Cc: gdb@sources.redhat.com
Date: Wed, 20 Feb 2002 13:49:07 -0500

Richard what follows is the short obscure answer (sorry).  I'll try to 
do the long (add to documentation answer, in about a week - this really 
does need to be documented.
------------

I would like to ask you, if anybody is willing to help me update our current 
version of gdb or at least take a quick look at it and tell me how things 
should work not.

http://www.opencores.org/cvsweb.shtml/or1k/gdb-5.0/

thanks for your help,
Marko

Re: Merging OC gdb with official gdb

[Andrew Cagney]

> Hi!
> 
> At opencores (www.opencores.org) we have a gdb-5.0 port to our or1k 
> architecture.
> We would like to join our sources into official version.
> Your current BFD already has needed or32 support.
> I have seen, that gdb went thought many internal changes, like regcache, etc.
> 
> I've looked at documentation, and it is outdated. Although there are promising 
> mails, like below one ;), there is not enough info for me to break through.

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.

As for your architecture the main things are:

- getting it to strictly use the multi-arch framework (the exception 
being if your platform has shared libraries)

- getting it to comply to gnu (and GDB) coding standards

- FSF paperwork

Otherwize it should drop in.  Take a look at one of the very recent 
targets (xstormy16?).

Andrew


> ------------
> From: Andrew Cagney <ac131313@cygnus.com>
> To: Richard.Earnshaw@arm.com
> Cc: gdb@sources.redhat.com
> Date: Wed, 20 Feb 2002 13:49:07 -0500
> 
> Richard what follows is the short obscure answer (sorry).  I'll try to 
> do the long (add to documentation answer, in about a week - this really 
> does need to be documented.
> ------------
> 
> I would like to ask you, if anybody is willing to help me update our current 
> version of gdb or at least take a quick look at it and tell me how things 
> should work not.
> 
> http://www.opencores.org/cvsweb.shtml/or1k/gdb-5.0/
> 
> thanks for your help,
> Marko
> 
> 

Re: Merging OC gdb with official gdb

[Marko Mlinar]

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.

> - 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.
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.

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?

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

> - FSF paperwork
already have it.

> Otherwize it should drop in.  Take a look at one of the very recent
> targets (xstormy16?).
ok.

thanks for your help,
Marko

Re: Merging OC gdb with official gdb

[Andrew Cagney]

> 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

Re: Merging OC gdb with official gdb

[Marko Mlinar]

On Monday 09 September 2002 18:01, Andrew Cagney wrote:
> > Andrew,
> >> - 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.
>
> >> Otherwize it should drop in.  Take a look at one of the very recent
> >> targets (xstormy16?).
> >
> > ok.

First, thanks for your help.

I've decided to go with xstormy example, but I have problems with 
documentation (:( sorry, I know nobody wants to do this), but I realy do not 
feel comfortable writing even with simple functions like: 
set_gdbarch_register_size.
I tried to figure out these things from other targets, but the problem is my 
knowledge on their architecture is very limited.

Where could I find more about gdbarch functions.

thanks,
Marko