GDB 5.0 for Tornado/VxWorks on PPC604e ?

GDB 5.0 for Tornado/VxWorks on PPC604e ?

[Alexander Povolotsky]

> Hello GDB experts,
> 
> What about GDB 5.0 for Tornado/VxWorks on PPC604e and other architectures
> ?
> Is WRS opposing to it or does someone from WRS is working on it ?
> 
> Also I would like to ask you the question on GDB v 4.12 (Actually WRS's
> incarnation called CrossWind).
> It has to do with "source directories" settings .
> >According to the documentation
> >(gdb) dir "/some/fully/qualified/source/path"
> >should set the source path to access the needed source file.
> >It does sets it, as indicated by
> >
> >(gdb) show dir 
> (it shows this directory prepended in front of $cdir and $cwd
> >
> >but, apparently, commmands
> >
> >(gdb) list filename.c:lineNumber
> >  or
> >(gdb) list filename:functionName
> >
> >still fail for most of such directories and source files in those ....
> >
> >changing directory to the one of interest prior to executing "list"
> commands as above 
> >
> >(gdb) cd "/some/fully/qualified/source/path"
> >
> >did not help either ...
> >
> >so using commands
> >
> >(gdb) info source
> >
> >and
> >
> >(gdb) info sources
> >
> >showed that the source visibility is ACTUALLY defined by the content
> "compilation directory" $cdir ONLY !
> >
> >We are using "Clearmake" in our multinested directories recursive "total"
> 
> >build process ....
> >The shell we are using is "bash" ....
> >
> >How could I change setting of "cdir"  - could I do it in .gdbinit ?
> >(and if yes, what would be the correct syntax) ?
> >Any way, what is the solution for this problem (we are using Tornado
> 1.0.1 
> >on Solaris 2.7 ) ?
> >
> >
> >Best Regards,
> >Alex Povolotsky
> 
From scottb@netwinder.org Thu Sep 07 07:47:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: GDB Mailing List <gdb@sourceware.cygnus.com>
Subject: solib.c won't compile on ARM Linux...
Date: Thu, 07 Sep 2000 07:47:00 -0000
Message-id: <39B7A95F.78C4704D@netwinder.org>
X-SW-Source: 2000-09/msg00078.html
Content-length: 2083

gcc -c -g -O2    -I. -I../../gdb-main/gdb -I../../gdb-main/gdb/config
-DHAVE_CONFIG_H
-I../../gdb-main/gdb/../include/opcode -I../../gdb-main/gdb/../readline/..
-I../bfd -I../../gdb-main/gdb/../bfd
-I../../gdb-main/gdb/../include -I../intl -I../../gdb-main/gdb/../intl
-DUI_OUT=1 -Wimplicit -Wreturn-type -Wcomment
-Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized 
../../gdb-main/gdb/solib.c
../../gdb-main/gdb/solib.c:163: field `lm32' has incomplete type
../../gdb-main/gdb/solib.c: In function `first_link_map_member':
../../gdb-main/gdb/solib.c:1043: sizeof applied to an incomplete type
../../gdb-main/gdb/solib.c:1044: invalid use of undefined type `struct
r_debug32'
../../gdb-main/gdb/solib.c: In function `open_symbol_file_object':
../../gdb-main/gdb/solib.c:1104: storage size of `lmcopy' isn't known
../../gdb-main/gdb/solib.c: In function `current_sos':
../../gdb-main/gdb/solib.c:1261: sizeof applied to an incomplete type
../../gdb-main/gdb/solib.c: In function `symbol_add_stub':
../../gdb-main/gdb/solib.c:1324: warning: `lowest_index' might be used
uninitialized in this function
../../gdb-main/gdb/solib.c: In function `info_sharedlibrary_command':
../../gdb-main/gdb/solib.c:1650: warning: `addr_width' might be used
uninitialized in this function
../../gdb-main/gdb/solib.c:1651: warning: `addr_fmt' might be used uninitialized
in this function
../../gdb-main/gdb/solib.c: At top level:
../../gdb-main/gdb/solib.c:147: storage size of `debug32_copy' isn't known
make[1]: *** [solib.o] Error 1
make[1]: Leaving directory `/home/scottb/cvstree/gdb-main-build/gdb'
make: *** [all-gdb] Error 2

I had a look at this.  The problem is in configuration. 
HAVE_STRUCT_LINK_MAP32=1 and I don't have it.  I had a look at the test, and it
seems to try to compile a file with #include sys/link.h.  I don't have any such
file.  I suspect the compile fails, and the define gets set to 1 incorrectly. 
I'm using glibc 2.1.3 on a NetWinder.

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From eliz@delorie.com Thu Sep 07 08:02:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kettenis@wins.uva.nl
Cc: jcownie@etnus.com, gdb@sources.redhat.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Thu, 07 Sep 2000 08:02:00 -0000
Message-id: <200009071500.LAA07756@indy.delorie.com>
References: <200009070855.EAA00749@albacore> <200009071009.e87A9oh14388@debye.wins.uva.nl>
X-SW-Source: 2000-09/msg00079.html
Content-length: 1217

>   Date: Thu, 7 Sep 2000 12:09:50 +0200 (MET DST)
>   From: Mark Kettenis <kettenis@wins.uva.nl>
>
>   Yep.  This means that getting HW watchpoints working for
>   multi-threaded processes is a bit difficult, since GDB expects them to
>   be process-wide.  So any HW watchpoints will have to be inserted in
>   *all* threads, not just one as we do now.
>
>   Eli, this probably means that adding the debugging registers to GDB's
>   register cache isn't a good idea.  Something more specialized is
>   needed, i.e. a native-dependent interface that updates the address and
>   control register in all threads.  This might implicate that keeping
>   the actual HW watchpoint support a native-only thing is a good idea.

Why ``native-dependent'' and not ``target-dependent''?  Won't the same
problem affect any multithreaded ia32 target?  Or am I missing
something?

In any case, would a special array of debug registers be an okay
solution?  The elements of that array will be set by
ia32_insert_watchpoint and ia32_remove_watchpoint (to be written), and
target-dependent subroutines which resume the inferior and get control
when the inferior is stopped will access that array to pass the
registers to the debuggee.
From shaunj@gray-interfaces.com Thu Sep 07 09:02:00 2000
From: "Shaun Jackman" <shaunj@gray-interfaces.com>
To: "gdb list" <gdb@sources.redhat.com>
Subject: Re: RDI target via UDP and router (don't)
Date: Thu, 07 Sep 2000 09:02:00 -0000
Message-id: <003b01c018e4$f2978400$6801a8c0@gray.internal>
References: <20000906225725.C7007@visi.com>
X-SW-Source: 2000-09/msg00080.html
Content-length: 2262

The Jeeni really should be using Angel over TCP. Why they decided on UDP is
beyond me.
As far as I understand it, Angel over UDP is identical to Angel over serial,
with the serial chunks broken up to datagrams.
TCP would provide a reliable streamed connection identical to the original
serial transport method.
Like you said, Angel has to run over a reliable transport medium. If they
haven't built reliability (ie lost packet sense, out of order, etc...) into
their Angel over UDP protocol, it's seriously broken.
I wonder if we could convince them to do an Angel over TCP firmware version?

Cheers,
Shaun

----- Original Message -----
From: Grant Edwards <grante@visi.com>
To: <gdb@sources.redhat.com>
Sent: Wednesday, 2000 September 06 21.57
Subject: RDI target via UDP and router (don't)


>
> Hello ARM fans!
>
> I discovered today that using the Jeeni RDI target via a router is bad
news.
>
> The Angle Debug Protocol used by the RDI target is fragile and can't
handle
> any packet loss.  Rather than UDP, it really should be using the mythical
> "reliable datagram" or "sequential packet" service spoken of in the
"socket"
> man-page of some Unices.  Unfortunately nobody ever got around to
> implementing either of those (AFAIK).
>
> So, if your router is not absolutely, postitively, 100% reliable, it's
going
> to break the Angle/UDP connection between gdb and the Jeeni.  I've no idea
> _why_ our router was dropping UDP packets, but every minute or two the
damn
> thing (the router) apparently flushes its ARP tables, because it sends an
> ARP request out to find the Ethernet address of the Jeeni.  If it receives
> an Angel/UDP packet from gdb destined for the Jeeni before it gets an ARP
> reply from the Jeeni, it flushes the UDP packet, and the gdb<-->Jeeni
> connection seizes up.
>
> It's possible that receiving an ARP request caused the Jeeni to loose a
UDP
> packet somehow -- I don't think I could differentiate between these two
> cases with the data I gathered.
>
> Either way, using the router caused the Angel protocol connection to die
> within a minute or two of starting up gdb.  Reconfiguring things so that
the
> Jeeni was on the same subnet as the gdb host made the problem go away.
>
> --
> Grant Edwards
> grante@visi.com
>
>