From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Povolotsky To: gdb@sources.redhat.com Subject: GDB 5.0 for Tornado/VxWorks on PPC604e ? Date: Thu, 07 Sep 2000 06:01:00 -0000 Message-id: X-SW-Source: 2000-09/msg00077.html > 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 To: GDB Mailing List 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 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 > > 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" To: "gdb list" 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 To: 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 > >