Porting advice

Porting advice

[Svein E. Seldal]

Hello,

I'm working on porting a new target for gdb, the tic4x, or Texas 
Instruments TMS320C3x and TMS320C4x (DSP's). I have been looking into 
the gdb sources and I have a couple of questions regarding the porting job.

The configuration patch is done, and since tic4x exists already in 
binutils, bfd and opcodes are also done. The only work needed, it seems 
like, is gdb and sim.

- What approach is the best when doing a new port? I have read the gdb 
internals manual, but I must admit that I dont quite get the overall 
picture from it.

- Are there any other targets which serve good as a "template"? I see 
references in the gdbint manual to d10v. Please note that the tic4x 
target will always be a cross target, never native.

- For a cross target what is required?

I have written a TCP gdbserver which accepts the standard gdb remote 
commands which talks to actual hardware. My primary use of gdb is to be 
able to talk to this gdbserver and to examine the runtime code, set 
breakpoints, etc. My second (distant) use of gdb is to use a simulator.

My problem is that I cannot find any references to any cross targets not 
linking in a simulator. Is this the case? If I edit my local 
gdb/config/tic4x/tic4x.mt and remove the "SIM = " line, compilation of 
gdb croaks and dies because of missing sim symbols. Is it possible to 
build a target gdb without the usage of a simulator?

- What does the "SIM_OBS =" line in the gdb/config/tic4x/tic4x.mt file do?

- Should I enable multi-arch support now? I mean, this being a totally 
new target and all?

- What "struct gdbarch" methods do I need to have implemented in 
gdb/tic4x-tdep.c? Is there a collected documentation of the methods 
somewhere? (I've read gdbarch.sh, but more detailed examples would be 
very nice.)


Hmmm.. Too many questions to get any consistent answer... Well, lets try 
anyway...

Regards,
Svein Seldal

Re: Porting advice

[Andrew Cagney]

> Hello,
> 
> I'm working on porting a new target for gdb, the tic4x, or Texas Instruments TMS320C3x and TMS320C4x (DSP's). I have been looking into the gdb sources and I have a couple of questions regarding the porting job.
> 
> The configuration patch is done, and since tic4x exists already in binutils, bfd and opcodes are also done. The only work needed, it seems like, is gdb and sim.
> 
> - What approach is the best when doing a new port? I have read the gdb internals manual, but I must admit that I dont quite get the overall picture from it.

People typically start with an existing port, as a template, and then 
modify it.

> - Are there any other targets which serve good as a "template"? I see references in the gdbint manual to d10v. Please note that the tic4x target will always be a cross target, never native.

The d10v is currently the best reference target - as it is the most 
up-to-date.

Avoid anything with the word deprecated in it.

> - For a cross target what is required?

<cpu>-tdep.c.

> I have written a TCP gdbserver which accepts the standard gdb remote commands which talks to actual hardware. My primary use of gdb is to be able to talk to this gdbserver and to examine the runtime code, set breakpoints, etc. My second (distant) use of gdb is to use a simulator.
> 
> My problem is that I cannot find any references to any cross targets not linking in a simulator. Is this the case? If I edit my local gdb/config/tic4x/tic4x.mt and remove the "SIM = " line, compilation of gdb croaks and dies because of missing sim symbols. Is it possible to build a target gdb without the usage of a simulator?

--target=ia64-linux-gnu

will give you a cross debugging ia64 with no simulator.

> - What does the "SIM_OBS =" line in the gdb/config/tic4x/tic4x.mt file do?
> 
> - Should I enable multi-arch support now? I mean, this being a totally new target and all?

Yes.  Non multi-arch targets are no longer accepted.

> - What "struct gdbarch" methods do I need to have implemented in gdb/tic4x-tdep.c? Is there a collected documentation of the methods somewhere? (I've read gdbarch.sh, but more detailed examples would be very nice.)

gdbint.texinfo lists most.  As for what is needed see d10v (however, 
take care, the list of required methods is very much in flux).

Andrew

Re: Porting advice

[Svein E. Seldal]

Andrew Cagney wrote:
> The d10v is currently the best reference target - as it is the most 
> up-to-date.

To better understand the d10v port, I would like to briefly look at the 
d10v architecture. I have tried to find the "D10V Architecture Manual" 
from Mitsubishi's home page. But they have hopeless homepages where it 
is impossible to find anyting. (Even Google did not turn up with any 
usable links.)

Does anyone have a link to the manufacturers d10v homepage, or a link to 
the manual, please?

Svein

Re: Porting advice

[Andrew Cagney]

> Andrew Cagney wrote:
> The d10v is currently the best reference target - as it is the most up-to-date.
> 
> To better understand the d10v port, I would like to briefly look at the d10v architecture. I have tried to find the "D10V Architecture Manual" from Mitsubishi's home page. But they have hopeless homepages where it is impossible to find anyting. (Even Google did not turn up with any usable links.)
> 
> Does anyone have a link to the manufacturers d10v homepage, or a link to the manual, please?

I've only printed manuals :-(  There was a paper giving an overview 
presented at an architecture conference a few years back.

Andrew

Porting advice or documentation request

[Svein E. Seldal]

Hi all,

I'm working on this new gdb port, and more than often I'm stuck. I have 
been told that the d10v port is the most authorative template for how 
new targets should be written. Unfortunately it is impossible to learn 
anything about the d10v's hardware architecture on the net, so I find it 
a bit difficult to template from.

It is simple enough to copy the functions and such from the d10v's 
implemenation, but in many cases I have *no* idea what the function I'm 
implementing really does. E.g. what parts of the port are spesialised 
d10v parts and should not be copied, and which are general port 
implementations that should be copied, etc.

One pratical example is the struct frame_unwind table included in the 
target. It refers to "xxx_frame_this_id" and "xxx_frame_prev_register", 
which in turn performs some magic that I'm unable to make out. I 
understand from the docs that the xxx_frame_this_id should return the 
calling function's frame, but in the d10v port, there is much code that 
I dont understand what is.

And the list of gdbarch funtions are long, and my general impression is 
that I dont know which functions are required and which are there for 
special cases. What functions *must* I have implemented?

So please, please, please, does anyone have any pointers on how to 
understand gdb to get this port up and running? How can I best 
understand the gdbarch functions? I've read the gdb, gdb-internals 
manual and I'm grepping a lot of code, debugging gdb itself, but I'm 
still confused and uninformed. :(

So far I have at least a little bit. I have this TCP remote GDB server 
which talks to real hardware. And I've managed to get communication with 
it from GDB. I am able to place breakpoints, step code, etc.  But as 
soon as I do anything more complex, like dumping the frame or printing 
the registers it either dies with a segfault or issues a gdb error. But 
again, generally I dont really know *why* things fail, because I dont 
understand *what* I need to do or *where* to put it.

... help please.


Regards,
Svein

Re: Porting advice or documentation request

[Richard Earnshaw]

> Hi all,
> 
> I'm working on this new gdb port, and more than often I'm stuck. I have 
> been told that the d10v port is the most authorative template for how 
> new targets should be written. Unfortunately it is impossible to learn 
> anything about the d10v's hardware architecture on the net, so I find it 
> a bit difficult to template from.

I can sympathise.  I've tried on a couple of occasions to update the ARM 
target to use the new interfaces and I've repeatedly run into situations 
where the GDB's abstraction model is just not obvious from staring at the 
code.

Andrew, I think we really need a 10,000 ft view document on gdb's internal 
architecture to complement the list of macros that a target can define...

R.

Re: Porting advice or documentation request

[Elena Zannoni]

Richard Earnshaw writes:
 > > Hi all,
 > > 
 > > I'm working on this new gdb port, and more than often I'm stuck. I have 
 > > been told that the d10v port is the most authorative template for how 
 > > new targets should be written. Unfortunately it is impossible to learn 
 > > anything about the d10v's hardware architecture on the net, so I find it 
 > > a bit difficult to template from.
 > 
 > I can sympathise.  I've tried on a couple of occasions to update the ARM 
 > target to use the new interfaces and I've repeatedly run into situations 
 > where the GDB's abstraction model is just not obvious from staring at the 
 > code.
 > 
 > Andrew, I think we really need a 10,000 ft view document on gdb's internal 
 > architecture to complement the list of macros that a target can define...
 > 
 > R.
 > 


I think checking out the new i386 frame branch could help here
too. Mark updated the i386 to use the new frame stuff, so that could
be used as example.

elena

Re: Porting advice or documentation request

[Andrew Cagney]

> Richard Earnshaw writes:
>  > > Hi all,
>  > > 
>  > > I'm working on this new gdb port, and more than often I'm stuck. I have 
>  > > been told that the d10v port is the most authorative template for how 
>  > > new targets should be written. Unfortunately it is impossible to learn 
>  > > anything about the d10v's hardware architecture on the net, so I find it 
>  > > a bit difficult to template from.
>  > 
>  > I can sympathise.  I've tried on a couple of occasions to update the ARM 
>  > target to use the new interfaces and I've repeatedly run into situations 
>  > where the GDB's abstraction model is just not obvious from staring at the 
>  > code.
>  > 
>  > Andrew, I think we really need a 10,000 ft view document on gdb's internal 
>  > architecture to complement the list of macros that a target can define...

For a 10 000' view there's the multi-arch white paper, and posts such as:
Ref: cooked regcache -> frame (follow the links in it)
http://sources.redhat.com/ml/gdb/2003-05/msg00287.html
Ref: WIP: Register doco
http://sources.redhat.com/ml/gdb/2002-07/msg00202.html

One thing that is missing, though, is a migration strategy that is known 
to work (like the convert to multi-arch doco).  Can I suggest starting 
with a set_gdbarch_deprecated_* method and working down (see gdbarch.h 
for the replacement).  I think trying to start from the other end - 
trying to eliminate all instances of something like 
deprecated_registers[] say  - will run into real problems.

> I think checking out the new i386 frame branch could help here
> too. Mark updated the i386 to use the new frame stuff, so that could
> be used as example.

Yes, definitly.  I've been told that a third architecture is lurking in 
the wings.

Andrew

Re: Porting advice

[Corey Minyard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You would save yourself a lot of work if you went to Google and type "TI 
DSP gdb".

It gives the following web site: http://www.elec.canterbury.ac.nz/c4x/

- -Corey

Svein E. Seldal wrote:

| Hello,
|
| I'm working on porting a new target for gdb, the tic4x, or Texas 
Instruments TMS320C3x and TMS320C4x (DSP's). I have been looking into 
the gdb sources and I have a couple of questions regarding the porting job.
|
| The configuration patch is done, and since tic4x exists already in 
binutils, bfd and opcodes are also done. The only work needed, it seems 
like, is gdb and sim.
|
| - What approach is the best when doing a new port? I have read the gdb 
internals manual, but I must admit that I dont quite get the overall 
picture from it.
|
| - Are there any other targets which serve good as a "template"? I see 
references in the gdbint manual to d10v. Please note that the tic4x 
target will always be a cross target, never native.
|
| - For a cross target what is required?
|
| I have written a TCP gdbserver which accepts the standard gdb remote 
commands which talks to actual hardware. My primary use of gdb is to be 
able to talk to this gdbserver and to examine the runtime code, set 
breakpoints, etc. My second (distant) use of gdb is to use a simulator.
|
| My problem is that I cannot find any references to any cross targets 
not linking in a simulator. Is this the case? If I edit my local 
gdb/config/tic4x/tic4x.mt and remove the "SIM = " line, compilation of 
gdb croaks and dies because of missing sim symbols. Is it possible to 
build a target gdb without the usage of a simulator?
|
| - What does the "SIM_OBS =" line in the gdb/config/tic4x/tic4x.mt file do?
|
| - Should I enable multi-arch support now? I mean, this being a totally 
new target and all?
|
| - What "struct gdbarch" methods do I need to have implemented in 
gdb/tic4x-tdep.c? Is there a collected documentation of the methods 
somewhere? (I've read gdbarch.sh, but more detailed examples would be 
very nice.)
|
|
| Hmmm.. Too many questions to get any consistent answer... Well, lets 
try anyway...
|
| Regards,
| Svein Seldal
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+iIY2IXnXXONXERcRAqE7AJ9j/e7UrnM/20Yhzy/rjYX9Wo9MIACfaSEB
buydFbeMAoXp7y7vqacaGjY=
=5AlP
-----END PGP SIGNATURE-----

Re: Porting advice

[Svein E. Seldal]

Corey Minyard wrote:
> You would save yourself a lot of work if you went to Google and type "TI 
> DSP gdb".
 >
 > It gives the following web site: http://www.elec.canterbury.ac.nz/c4x/

Thanks.

I am well aware of this page. In fact, all tic4x work is originating 
from that page/author. I am cooperating with Michael Hayes (the author) 
on this, and therefore I have become the binutils maintainer for the 
tic4x port; which mostly was based on his patches. What's found on this 
website is old and outdated.

Now, its time for me to look at gdb for this target. I have a tic4x 
patch for gdb from Michael. An old semi-working one, but I have one. My 
job now would be to adopt this patch to gdb HEAD (including things like 
multiarch and such). -- And eventually I intend to maintain the gdb port 
  together with binutils.

So here I am, needing to understand gdb. Thus all the questions....


Svein

Re: Porting advice

[Corey Minyard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I apologize.  I assumed from your email that you were starting from 
scratch, I probably missed something.

- -Corey

Svein E. Seldal wrote:

| Corey Minyard wrote:
|
|> You would save yourself a lot of work if you went to Google and type 
"TI DSP gdb".
|
| >
| > It gives the following web site: http://www.elec.canterbury.ac.nz/c4x/
|
| Thanks.
|
| I am well aware of this page. In fact, all tic4x work is originating 
from that page/author. I am cooperating with Michael Hayes (the author) 
on this, and therefore I have become the binutils maintainer for the 
tic4x port; which mostly was based on his patches. What's found on this 
website is old and outdated.
|
| Now, its time for me to look at gdb for this target. I have a tic4x 
patch for gdb from Michael. An old semi-working one, but I have one. My 
job now would be to adopt this patch to gdb HEAD (including things like 
multiarch and such). -- And eventually I intend to maintain the gdb 
port  together with binutils.
|
| So here I am, needing to understand gdb. Thus all the questions....
|
|
| Svein


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+iMLUIXnXXONXERcRAjQYAKCoqv+I3w0NWbwHT7zBc7wTJE+ZzwCgqxdS
/U6lDrYf0gcsNoRnnF41T6w=
=6K9m
-----END PGP SIGNATURE-----