This is the mail archive of the
mailing list for the GDB project.
Re: GDB for VxWorks?
> In the GDB mailing list archives, I've found two postings from you
> regarding GDB for Vxworks.
> I've several questions concerning that:
> * Will this be committed to GDB mainstream? Any time soon?
The answer unfortunately is no. It is true that we do have a version
of GDB that works with Tornado 2.x and 653, but it is simply nowhere
near submitable. I am not going to enumerate all the reasons for this,
but although I'm still planning on submitting all the other ports we
made (native win32 and ia64-hpux), this one is not in our plans at all.
> * Is the patch kept current w.r.t. the latest GDB release? How much work
> would be necessary to port it to GDB 6.6?
Way too much work. It would most probably be less work to do the port
again from scratch. It's a bit of work, but I don't think it's all
that difficult. The port itself uses ELF and DWARF, so a lot of standard
pieces can be reused. Support for the various chips you mentions is
also already there. So all you really need to do is implement support
for WTX. From our experience, the only tricky parts are:
. Implement the main event loop
. Get some of the information we need, such as the list of task
(aka "threads"). You'll need to poke directly in the memory
for that using gopher, at least with 653. There is not support
for that that's provided by the system. Check "gdb.tcl" in
the tornado install files, this gives a bit of insight on that.
> * Does this work with VxWorks 5, VxWorks 6, or both?
VxWorks 5 and 653.
> * What target hardware platforms does it support (we use Pentium, PPC
> and XScale)?
We only support x86 and ppc. The patch we inherited supported many
platforms, such as hppa, or m68k, but we are not testing on these,
so I don't know. I don't think xscale is supported, however.
> * How can I download it (our firewall does not allow CVS access, only
> http and ftp)?
At the present moment, we do not provide public access to this patch.
I don't think it would be much use to you either. I recommend instead
that you contact WindRiver directly; they should be able to provide you
the debugger and their sources - they were the original implementors of