From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: GDB Discussion Subject: gdb/remote - I/O Date: Fri, 23 Mar 2001 15:36:00 -0000 Message-id: <3ABBDDE4.7C22709D@cygnus.com> X-SW-Source: 2001-03/msg00260.html Hello, The existing remote protocol doesn't support input vis: GDB -> target (ignoring the ``target cisco'' hack that just sends raw characters). I think the current semantics for output are also weak and I'd like to change them. In the below I'll try to sketch out the basic idea. As way of background, the remote protocol is not symetric. GDB initiates everything and then the target (eventually) responds. For instance: -> g (read registers) <- 12345678123456781234567812345678 (register bytes in hex) A target is continued with: -> c (continue) (time passes) <- T.... (stop with info) To halt the target: -> c (continue) (time passes) (time passes) <- T.... (stop) Where is the CNTRL-C character but could be some other out-of-band character. Appart from the ``O'' (output) packet, the target never initiates anything. Output: I'd like to change the protocol so that the output mechanism is synchronous. That is, instead of: -> c (continue) <- O.... (hex output) <- O.... (more hex output) <- T... (stop) The output mechanism is treated like any other continue response. That is, it halts the target and waits for further input vis: -> c (continue) <- o (implied halt) -> c (continue) <- o (implied halt) -> c (continue) <- T... (stop) Pragmatics: It makes the behavour consistent with the rest of the remote protocol. The additional round trip is acceptable since the objective is to implement a primative but (relativly) reliable console. The objective is not to implement a high speed data link. It is possible to implement this in the existing GDB without significant change. Input: For input, GDB would first get the targets attention () then pass down the input and finally resume the target vis: -> c (continue) <- T (stop) -> i <- OK -> c (continue) ..... <- T.... (stop) A refinement might see: -> c (continue) <- T (stop) -> c (continue with input) .... <- T.... (stop) Pragmatics: It is slow, oops! The objective is to implement a functional console, not a fast console :-) The interaction is consistent with the rest of the remote protocol - GDB initiates the transaction. I think it is possible to modify an existing GDB so that it will behave this way. It would probably rely on ``remote *async'' as remote.c would need to block on both the console and the target. Unlike other implementations this doesn't involve making the protocol asynchronous. Consequently, it should keep the target simpler. Flow control is a target problem. That data gets sent across, ready or not :-) thoughts, Andrew >From tanvir.hassan@tumisoftware.com Fri Mar 23 16:02:00 2001 From: Tanvir Hassan To: 'Daniel Berlin' , Tanvir Hassan Cc: 'Michael Elizabeth Chastain' , gdb@sourceware.cygnus.com Subject: RE: using GDB 5 on Solaris 7 with Sun WS5.0 Date: Fri, 23 Mar 2001 16:02:00 -0000 Message-id: <3DD49A5C2322D411B6AE00C00D01611506CD84@HELIOS> X-SW-Source: 2001-03/msg00261.html Content-length: 4409 Hmmm. Can I use a c++filt/dem type program that can take mangled names and produce demangled names to get around the name mangling problem? Also, I still cannot debug a program unless I include "-xs". Is the psymtab stuff not meant to deal with non "-xs" code? Or am I stuck using "-xs" to debug under WS5.0 and GDB on Solaris 7? -----Original Message----- From: Daniel Berlin [ mailto:dan@www.cgsoftware.com ] Sent: Friday, March 23, 2001 2:35 PM To: Tanvir Hassan Cc: 'Michael Elizabeth Chastain'; gdb@sourceware.cygnus.com Subject: RE: using GDB 5 on Solaris 7 with Sun WS5.0 On Fri, 23 Mar 2001, Tanvir Hassan wrote: > Here's the stuff I get from "man CC" on SunWorkshop 5 C++: > > Note that -compat=5 (which lets me use STL) will set the __cplusplus macro > to "199711L". I don't know if that helps in determining which ABI those > guys are following. Also, I tried to compile helloworld.cpp with -g and see > if the newest snapshot (23/Mar/2001) could debug it without me resorting to > -xs and it cannot. Is there an option or config.h option that I need to > enable psymtab stuff? Nope. It's automagic. > > > -compat[=(4|5)] > Sets the compiler to be compatible with 4.0.1, > 4.1, and 4.2 compilers; or with full 5.0. This > option controls the preprocessor __cplusplus > macro. > > The C++ compiler has two principal modes. One > accepts the semantics and language defined by the > Annotated C++ Reference Manual (ARM) and used in > the 4.2 compiler (the compatibility mode, -com- > pat=4). The other accepts constructs according to > the ANSI/ISO standard (standards mode, -compat=5). > These two modes are incompatible with each other > because the ANSI/ISO standard forces significant, > incompatible changes in name mangling, vtable lay- > out, and other ABI details. These two modes are > differentiated by the -compat option as shown in > the following values. You are misreading it. All this means is that they changed their ABI to be able to support the ISO standard, not that they are using a standard ABI. They are most certainly not. We have 0 support for their ABI, so you won't be able to debug in any useful way. > > Value Meaning > > -compat=4 Compile for compatibility with C++ > 4.0.1, C++ 4.1, and C++ 4.2 (Sets > __cplusplus macro to 1.) > > -compat=5 Compile with full C++ 5.0 features. > (Sets __cplusplus macro to > 199711L.) > > Defaults: > > If the -compat option is not specified, -compat=5 > is assumed. If only -compat is specified, -com- > pat=4 is assumed. > > Interactions: > > The -xarch=v9 option and the -compat[=4] option > are not supported when used together. > > -----Original Message----- > From: Michael Elizabeth Chastain [ mailto:chastain@cygnus.com ] > Sent: Friday, March 23, 2001 9:23 AM > To: gdb@sourceware.cygnus.com; tanvir.hassan@tumisoftware.com > Subject: Re: using GDB 5 on Solaris 7 with Sun WS5.0 > > > Hi Tanvir, > > > I have heard that someone might have changed GDB to do "lazy" loading > > of symbols by reading them from the *.o instead of the exe and thus > > obviating the need for "-xs", but I don't see any mention of this in > > any of the source. > > That is the "partial symtab" (psymtab) code. > > > 2) the name mangling/vtable scheme of Sun WS5.0 is apparently using the > > ISO/ANSI ABI standard and GDB cannot deal with it (it needs an new BFD to > > handle this? or is there a generic name de-mangling place in the code?) > > Recent snapshots of gdb, and the current CVS version of gdb, operate with > the new multi-vendor C++ ABI: > > http://reality.sgi.com/dehnert_engr/cxx/cxx-summary.html > > If you could provide a URL or an ISO reference number for that "ISO/ANSI > ABI standard", I could check if it's the same as the "new ABI" standard > that we're working on supporting. > > Michael Elizabeth Chastain > > "love without fear" > >From ac131313@cygnus.com Fri Mar 23 18:23:00 2001 From: Andrew Cagney To: GDB Announce , GDB Discussion Subject: [gdb] OBSOLETE m88k platform Date: Fri, 23 Mar 2001 18:23:00 -0000 Message-id: <3ABC0525.CADF7070@cygnus.com> X-SW-Source: 2001-03/msg00262.html Content-length: 641 [Reply-to: GDB Discussion < gdb AT sources DOT redhat DOT com > ] Hello, As part of GDB 5.1, the m88k platform has been identified as a candidate for obsolescence. This platform: o definitly no longer builds o has no active maintainer ``Configurations that have been declared obsolete in this release have been commented out. Unless there is activity to revive these configurations, the next release of GDB will have their sources permanently REMOVED.'' If you have any comments or questions on this, please send them to the GDB Discussion group. Andrew Andrew Cagney Acting Head GDB Maintainer >From ac131313@cygnus.com Fri Mar 23 18:28:00 2001 From: Andrew Cagney To: GDB Announce , GDB Discussion Subject: [gdb] OBSOLETE Macintosh(tm) MPW(tm) platform Date: Fri, 23 Mar 2001 18:28:00 -0000 Message-id: <3ABC062A.AE99D47@cygnus.com> X-SW-Source: 2001-03/msg00263.html Content-length: 729 [Reply-to: GDB Discussion < gdb AT sources DOT redhat DOT com > ] Hello, Please note: This is not MacOS X As part of GDB 5.1, the Macintosh(tm) MPW(tm) platform has been identified as a candidate for obsolescence. This platform: o probably no longer builds o still uses *-xdep.c o has no active maintainer ``Configurations that have been declared obsolete in this release have been commented out. Unless there is activity to revive these configurations, the next release of GDB will have their sources permanently REMOVED.'' If you have any comments or questions on this, please send them to the GDB Discussion group. Andrew Andrew Cagney Acting Head GDB Maintainer >From eliz@delorie.com Sat Mar 24 00:44:00 2001 From: Eli Zaretskii To: bronson@trestle.com Cc: gdb@sourceware.cygnus.com Subject: Re: Trapping system calls Date: Sat, 24 Mar 2001 00:44:00 -0000 Message-id: <200103240844.DAA06451@indy.delorie.com> References: <20010322105918.H16210@trestle.com> X-SW-Source: 2001-03/msg00264.html Content-length: 435 > Date: Thu, 22 Mar 2001 10:59:18 -0800 > From: bronson@trestle.com (Scott Bronson) > > Is there any way to break into GDB when a particular system call > is made? I want to trap every ioctl of a certain type. Short > of scattering thousands of breakpoints throughout the code, I could > find no way of doing this. Is there any reason why you couldn't put a breakpoint inside ioctl and filter the calls with breakpoint conditions? >From eliz@delorie.com Sat Mar 24 00:49:00 2001 From: Eli Zaretskii To: ac131313@cygnus.com Cc: gdb@sources.redhat.com Subject: Re: TODO vs bug data base Date: Sat, 24 Mar 2001 00:49:00 -0000 Message-id: <200103240849.DAA06565@indy.delorie.com> References: <3ABA1637.18A2EE1C@cygnus.com> X-SW-Source: 2001-03/msg00265.html Content-length: 905 > Date: Thu, 22 Mar 2001 10:11:51 -0500 > From: Andrew Cagney > > Does the bug tracking database superseed the bulk of the TODO file? > > I don't think the bug system can completly replace the TODO file - I'll > still expect to see it used to publically record GDB's release status > and file more generic TODO items. IMHO, TODO is not a repository for bugs, and neither should it be used for tracking bugs. Instead, it should include more general goals of GDB development. Bugs should only be included there if they require thorough rewrites of large portions of code. For example, the problems with supporting the new C++ ABI is something worthy of a TODO item, but only as a general issue, not a list of specific problems. If we need some list of specific bugs that should be solved before the next release is made, they should IMHO go into a separate file, not into TODO. >From eliz@delorie.com Sat Mar 24 01:02:00 2001 From: Eli Zaretskii To: ac131313@cygnus.com Cc: gdb@sources.redhat.com Subject: Re: demangle.h and ucase enums? Date: Sat, 24 Mar 2001 01:02:00 -0000 Message-id: <200103240902.EAA06844@indy.delorie.com> References: <3ABA364A.BCB09EA4@cygnus.com> X-SW-Source: 2001-03/msg00266.html Content-length: 1427 > Date: Thu, 22 Mar 2001 12:28:42 -0500 > From: Andrew Cagney > > http://gcc.gnu.org/codingconventions.html > http://www.gnu.org/prep/standards_25.html#SEC25 > > ``Please use underscores to separate words in a name, so that the Emacs > word commands can be useful within them. Stick to lower case; reserve > upper case for macros and enum constants, and for name-prefixes that > follow a uniform convention.'' > > Does anyone know how this should be interpreted? I think you need to take a good look at Emacs sources to understand what is meant by ``name-prefixes that follow a uniform convention'' ;-). Emacs sources use the_lower_case_with_underscores for naming functions and variables. They use upper-case letters in functions and variables which have special meaning. For example, each primitive whose name in Lisp is primitive-function is defined in C as Fprimitive_function, and each variale known in Lisp as built-in-variable is defined in C as Vbuilt_in_variable. These F and V prefixes are certainly following a uniform convention. > I've been working on the simplistic interpretation of ``enums are in > upper case'' but, looking at demangle.h other interpretations are > possible. Err... what do you see in demangle.h that is pertinent to the above issue? I don't see anything except that they use lower case for enums, which AFAIK is quite a wide-spread habit, including in Emacs. >From mcmahill@mtl.mit.edu Sat Mar 24 05:24:00 2001 From: mcmahill@mtl.mit.edu To: gdb@sources.redhat.com Subject: m88k Date: Sat, 24 Mar 2001 05:24:00 -0000 Message-id: X-SW-Source: 2001-03/msg00267.html Content-length: 478 Hi, I've heard m88k is scheduled for being removed. There are a small handful of people who i think are planning a m88k port of netbsd and I think that there was some work in the openbsd camp too. it will be several more months until i have any time to put in to it, but i'd hoped to hack some on an m88k box myself. it currently runs mach, but i'd like to 'fix' that. so i guess the only point of my email is to note that there are at least a few potential users. -Dan