Re: gdb and the vxworks target

[Till Straumann <strauman at SLAC dot Stanford dot EDU>]

Hi jtc.

Thanks for your reply.

jtc@redback.com wrote:

> >>>>> "Till" == Till Straumann <strauman@SLAC.Stanford.EDU> writes:
> Till> As of Version 5.4, WindRiver has more or less silently removed
> Till> support for the RDB protocol. This means that the gdb target
> Till> `vxworks' no longer works with VxWorks versions later than 5.3
>
> Till> However, there is another server on the vxWorks target talking a
> Till> different protocol, WDB, which at least is quite well documented.
>
> It's OK, but at least in the copy of the WDB spec I have there are
> some holes, such as in what set and at what offset each register is
> located for the get/fetch register commands.

Our Tornado docs (that came with Tornado II/ vxWorks 5.4 for NT [:-(]
provide a chapter about WDB that is quite extensive (though not complete
when it comes to nasty details). But they state e.g. that the register
commands
get/send an image of a REG_SET / FPREG_SET structure. In fact, this
was one of the easiest parts.

They even provide a header file, wdb.h, and sources for the xdr_XXX_YYY()
wrapper routines, which I am currently using. I figured that if someone
with the
FSF would talk to WRS, they perhaps would be willing to donate these
files (in the same way they donated vx-share).

> I wasn't able to find
> the WTX or WDB specs in the Tornado II documentation

Our docs cover WTX as well.

> We're using a WDB back end I hacked from Wind River's vxgdb sources
> remote-wtx.c module.  I've been meaning to re-write those bits so I
> could contribute it for the last year or so.  Unfortunately, it's a
> fairly low on my priority list.

I asked WRS for a copy of their gdb sources - no reply however. I decided
that
it would be faster and easier to implement the stuff by myself...

> If your code isn't similarly encumbered, and you're able to contribute
> it, it's probably a faster route to supplying WDB support to GDB users.

Well, it seems to work so far but it's still very new - the code would
have
to be shaked, of course.

>
> Till> I added support for WDB to `remote-vx.c' which means that gdb
> Till> can again talk to vxworks :-) The CPU dependent parts (a very
> Till> tiny piece of code) are currently only implemented for the
> Till> powerpc (I could easily add m68k, if there's any need).
>
> Did you maintain support for RDB in the process?  While WRS has
> dropped support for RDB, there may be vxworks users in the field that
> still use it.  We should continue to support it if at all possible.

Of course, RDB is still supported.
My code is included in the remote-vx.c file and is activated
by conditional compilation (the downside being that gdb can not support
both, RDB and WDB targets in one configuration). The WDB stuff was
not put into a separate file for two reasons:
     - some of the old code is also used for WDB.
     -  (I'm sorry to admit that I hate autoconf, configure, automake,
autowhatever
         I never had the time to properly learn it - I'd need some help
when it
         comes to change the Meta-Makefiles)

>
> If you kept RDB support, how much code for RDB and WDB are shared in
> remote-vx.c?  In our sources, remote-wdb is completely separate.

I guess that separating the WDB parts out of remote-vx.c
would not be too much trouble. However, some of the now `static' routines
would have to be exported from remote-vx.c. Depends also on whether
we want to support two different targets (RDB and WDB) in the same gdb
configuration.

>
> Till> Because WDB lacks some functionality that RDB had provided (on
> Till> the other hand, WDB adds new features), I also wrote a small
> Till> server which can be started on the target. This server
> Till> implements a subset of the RDB protocol, essentially the parts
> Till> which are necessary to remotely load files and lookup modules.
>
> When you talk about a "small server that can be started on the target",
> you're talking about something that runs on the vxWorks system, right?

Sure. I was thinking about how to implement the `load files', `get loaded
file information' etc. stuff. One possibility I envisioned was doing only
WDB calls.
However, because WDB (AFAIK) does not implement any load commands,
we would have to rely on vxWorks providing these services (i.e. the object
module loader).
I could have used the WDB_FUNC_CALL / WDB_DIRECT_CALL RPCs
to call e.g. `loadModuleAt'. However, passing parameters and return values

back and forth would have been quite cumbersome (need to allocate
memory on the target, copy its contents to the host and free the memory
again, catch errors, cleanup etc.).

I decided that it was much easier to implement a simple server
(350 lines of code) which does the VX_FP_INQUIRE, VX_BOOT_FILE_INQ,
VX_STATE_INQ and VX_LOAD command subset of RDB.  (The related gdb
client side parts needed no change at all). Of course, an alternative
would have been
to implement a full-fledged RDB server - however, implementing
breakpoints would have been much more difficult than letting the WDB agent

do the job. Hence the dual-protocol approach.

Note that it is not necessary to run my RDB server - gdb will still
work (with reduced functionality). Thus, it is also possible to
debug standalone applications which have WDB but no module loader
support. In this case, you must tell gdb which kernel image file to
read symbol information from.

> Another engineer here hacked code into my remote-wdb.c to support
> remotely loading files, but it works entirely with WDB.  Can you
> please explain more?

(see above)

How does your implementation work; can you explain more?

> We also have a WDB multiplexor so that multiple GDBs, each connected
> to a single vxWorks task, can debug a system.

Yeah, an important issue - however, I do not have a solution yet. Is your
multiplexor integrated in the gdb backend or independent? Is it available
to the public?

Of course, my tiny-RDB  server would have to be multi-connection capable,
too but this is easy.

>
>         --jtc

BTW: what's your name?

IMHO, my code has two goodies:

        target vxworks <target-ip>  <kernel-file>

the `target' command lets you specify the kernel image path
(useful if the local path and the remote path are not identical).
This extra parameter must be specified if tiny-RDB is not running.

        attach 0

attaches the debugger to the task that first hits any enabled
breakpoint.  (It's sometimes not possible to know which task
will run the piece of code you want to debug. This new feature
will catch it).

--- Till

PS: remember that I'm not on this list, please CC to my personal
address.