From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Snyder To: gdb-patches@sourceware.cygnus.com Subject: [PATCH] dejagnu framework for testing gdbserver Date: Thu, 19 Oct 2000 14:50:00 -0000 Message-id: <39EF6CAE.6258@redhat.com> X-SW-Source: 2000-10/msg00125.html The old gdb/testsuite/config/gdbserver.exp had not been used or updated since 1995, so I've rewritten it from scratch. My new version has been tested on linux x86 (with the same machine for host and target). Extensions and enhancements welcome. Since it's essentially a new file, I'll just include it here instead of a context diff. 2000-10-19 Michael Snyder * config/gdbserver.exp: Rewritten from the ground up, to make it compatible with the current dejagnu tree, and to make it work with the new "gdbserver" in libremote. >From jtc@redback.com Thu Oct 19 16:14:00 2000 From: jtc@redback.com (J.T. Conklin) To: "Josef Ezra" Cc: "Michael Snyder" , , "ezra, josef" , , Subject: Re: tracepoints implementation: bug in byte code generating. Date: Thu, 19 Oct 2000 16:14:00 -0000 Message-id: <5mvguo5spm.fsf@jtc.redback.com> References: <00c801c02c9a$fe671c90$6c219fa8@lss.emc.com> <39D8D1CE.3059@redhat.com> <004e01c039d8$774c1d50$6c219fa8@lss.emc.com> <39EF3020.3F6A@redhat.com> <005b01c039f6$f46b1390$6c219fa8@lss.emc.com> <39EF381C.7EE6@redhat.com> <006101c039f9$df09df60$6c219fa8@lss.emc.com> X-SW-Source: 2000-10/msg00126.html Content-length: 1731 >>>>> "Josef" == Josef Ezra writes: >> Any changes to the remote protocol can be discussed >> on this mailing list. Josef> Actually I had in mind a 'show protocol version' command (for Josef> backward compatibility) and a special read memory command (like Josef> "mxxxx,lll") which can be used at target side for special reads Josef> (in my case, it will show values in different memory scope). For better or for worse, the remote protocol is been designed such that support for individual features can be probed for at run time instead of having protocol versions. While I believe that this has allowed new command packets to be added to the protocol expediently, I also believe that a more formal design and review may have produced a better overall result. Even so, if at all possible, I think your new command should be probed at run time. Can you offer more details about your command packet? Is it a varient of the 'm' command, or a new command? What exactly do you mean by different memory scope? Is there a cooresponding 'M' command to write memory? Josef> If it will turn out to be very useful, I will suggest it in Josef> this forum. In my remote II protocol spec (which regulars on the list know that I've been working on-and-off for about a year, but has never been ready enough to publish :-( ), the read and write memory commands take a memory space argument. I was thinking about it being used (on a target specific basis) for things like the x86 i/o ports or PCI config space, etc. I haven't thought about how such things would get through GDB to the CLI, but I thought it was important enough that the protocol support such things. --jtc -- J.T. Conklin RedBack Networks >From jtc@redback.com Thu Oct 19 16:32:00 2000 From: jtc@redback.com (J.T. Conklin) To: Till Straumann Cc: gdb-patches@sources.redhat.com Subject: Re: gdb and the vxworks target Date: Thu, 19 Oct 2000 16:32:00 -0000 Message-id: <5mog0g5rva.fsf@jtc.redback.com> References: <39EF530C.8EC0F049@slac.stanford.edu> X-SW-Source: 2000-10/msg00127.html Content-length: 2651 >>>>> "Till" == Till Straumann 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. I wasn't able to find the WTX or WDB specs in the Tornado II documentation --- I got the impression that they (WRS) wants to hide such details under their proprietary libraries. That makes it a bit difficult for third party, open source, multi-platform tools like GDB. 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. 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. 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. 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. 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? 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? We also have a WDB multiplexor so that multiple GDBs, each connected to a single vxWorks task, can debug a system. --jtc -- J.T. Conklin RedBack Networks >From kevinb@cygnus.com Thu Oct 19 17:45:00 2000 From: Kevin Buettner To: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFC] Protoize solib.c Date: Thu, 19 Oct 2000 17:45:00 -0000 Message-id: <1001020004548.ZM4367@ocotillo.lan> References: <1001018035727.ZM23476@ocotillo.lan> X-SW-Source: 2000-10/msg00128.html Content-length: 217 On Oct 17, 8:57pm, Kevin Buettner wrote: > * solib.c (LM_ADDR, LM_NEXT, LM_NAME, IGNORE_FIRST_LINK_MAP_ENTRY, > open_symbol_file_object): Protoize. Committed. Thanks to Michael Chastain for reviewing the patch. >From kevinb@cygnus.com Thu Oct 19 18:00:00 2000 From: Kevin Buettner To: gdb-patches@sourceware.cygnus.com Subject: [PATCH RFC] Protoize sparc-nat.c, sparcl-tdep.c Date: Thu, 19 Oct 2000 18:00:00 -0000 Message-id: <1001020005952.ZM4471@ocotillo.lan> X-SW-Source: 2000-10/msg00129.html Content-length: 2066 More protoization... * sparc-nat.c (fetch_core_registers): Protoize. * sparcl-tdep.c (download): Protoize. Index: sparc-nat.c =================================================================== RCS file: /cvs/src/src/gdb/sparc-nat.c,v retrieving revision 1.3 diff -u -r1.3 sparc-nat.c --- sparc-nat.c 2000/07/30 01:48:27 1.3 +++ sparc-nat.c 2000/10/20 00:52:24 @@ -248,13 +248,21 @@ } } +/* Provide registers to GDB from a core file. + CORE_REG_SECT points to an array of bytes, which are the contents + of a `note' from a core file which BFD thinks might contain + register contents. CORE_REG_SIZE is its size. + + WHICH says which register set corelow suspects this is: + 0 --- the general-purpose register set + 2 --- the floating-point register set + + IGNORE is unused. */ + static void -fetch_core_registers (core_reg_sect, core_reg_size, which, ignore) - char *core_reg_sect; - unsigned core_reg_size; - int which; - CORE_ADDR ignore; /* reg addr, unused in this version */ +fetch_core_registers (char *core_reg_sect, unsigned core_reg_size, + int which, CORE_ADDR ignore) { if (which == 0) Index: sparcl-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/sparcl-tdep.c,v retrieving revision 1.6 diff -u -r1.6 sparcl-tdep.c --- sparcl-tdep.c 2000/07/30 01:48:27 1.6 +++ sparcl-tdep.c 2000/10/20 00:52:25 @@ -527,13 +527,10 @@ #define LOAD_ADDRESS 0x40000000 static void -download (target_name, args, from_tty, write_routine, start_routine) - char *target_name; - char *args; - int from_tty; - void (*write_routine) (bfd * from_bfd, asection * from_sec, - file_ptr from_addr, bfd_vma to_addr, int len); - void (*start_routine) (bfd_vma entry); +download (char *target_name, char *args, int from_tty, + void (*write_routine) (bfd *from_bfd, asection *from_sec, + file_ptr from_addr, bfd_vma to_addr, int len), + void (*start_routine) (bfd_vma entry)) { struct cleanup *old_chain; asection *section;