From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com (GDB Developers) Subject: Re: Library interface to GDB Date: Thu, 10 Jun 1999 17:00:00 -0000 Message-id: <5maeu7txma.fsf@jtc.redbacknetworks.com> References: <199906082353.QAA23739@alabama.wrs.com> X-SW-Source: 1999-q2/msg00152.html >>>>> "Todd" == Todd Whitesel writes: Todd> Agreed. I've worked on debugger products that parsed the output Todd> of the HP In-Circuit emulators' terminal interface, and it's a Todd> losing battle. Todd> HP themselves tried to write a gasket that would API-ify the Todd> emulators, so that client programs would not have to deal with Todd> the emulator output. This was cancelled after a couple years. >> A debugger GUI should use an API, not AI. :) Todd> API yes, but not necessarily function calls. Todd> I rather like the idea of a "protocol" command in GDB whose Todd> subcommands produce machine-readable output. Regardless of whether the GDB API is implemented by traditional function-calls; a wrapper layer that interacts with the existing CLI; a machine parsable protocol; or some other RPC mechanism, I believe a more fundemental question remains: what level of abstraction will the API present. After that question is resolved, we can discuss what the specific calls will be and how the API will be implemented. I think that we would want a fairly high level of abstraction, but perhaps much less than what is currently provided by the CLI. It is my impression that systems that sit atop GDB and interact via the CLI sometimes must do a lot of work to do simple things. Perhaps someone who has actually worked on/with such interfaces can share their experiences? One way to start might be to start breaking down the things that GDB does into broad categories. Once that list is complete, we could refine and layer those categories into a heirarchy. In the end, I think we'd have the raw information necessary to make design decisions. For example: Memory Operations read memory @ address w/ write memory @ address Register Operations read register write register Symbol Operations read symbol file convert address to symbol convert symbol to address Execution Options next ni step si continue Breakpoint Options create breakpoint delete breakpoint enable breakpoint disable breakpoint ... This is just a sample I whipped out off the top of my head. Going through the code, the documentation, etc. would yeild a more complete list. I'm not sure I have enough time to spearhead such a effort, but it seems that a lot of these categories could be taken on independently or in small groups. As a result, it shouldn't take that long to put something together... --jtc -- J.T. Conklin RedBack Networks >From ac131313@cygnus.com Thu Jun 10 17:15:00 1999 From: Andrew Cagney To: gdb@sourceware.cygnus.com Subject: New stream - gdb_stdlog/gdb_stddebug? Date: Thu, 10 Jun 1999 17:15:00 -0000 Message-id: <376053FF.3050D846@cygnus.com> X-SW-Source: 1999-q2/msg00154.html Content-length: 492 Hello, At present GDB has two output streams: gdb_stdout gdb_stderr I'd like to propose the addition of a third stream: gdb_stdlog OR gdb_stddebug that would be used by any debug/log messages. At present debug information is somewhat arbitrarily sent to either the stdout or the stderr stream. The intention here is to rationalize this so that it is clear where any (non output) messages should go. Anyone see any problems with this? Any better names? Andrew >From ac131313@cygnus.com Thu Jun 10 17:15:00 1999 From: Andrew Cagney To: gdb@sourceware.cygnus.com Subject: New option? --trascript=FILE Date: Thu, 10 Jun 1999 17:15:00 -0000 Message-id: <376052AA.A66D599F@cygnus.com> X-SW-Source: 1999-q2/msg00153.html Content-length: 1130 Hello, I'd like to propose a new option ``--transcript=FILE'' that records all user interface interactions that occure when GDB is running. The format of the file would be: ::= | ::= a complete command ready to feed into the CLI ::= "#" text... for instance: $ gdb --transcript=LOG ..... (gdb) target sim Connected to the simulator (gdb) load File loaded (gdb) break main Breakpoint ... (gdb) run main.c:main() reached (gdb) quit $ would create: target sim #Connected to the simulator load #File loaded break main #Breakpoint ... run #main.c:main() reached quit which would then in turn allow: $ gdb -nx -x LOG ..... Connected to the simulator File loaded Breakpoint ... main.c:main() reached $ Apart from the general idea. Does anyone object to the choice of option name? Down the track we can see about commands that can control this. Andrew PS: If you look carefully, I've omitted a detail - the ``quit'' should prompt the user. That wouldn't appear in the transcript any way. >From ac131313@cygnus.com Sat Jun 12 18:45:00 1999 From: Andrew Cagney To: gdb@sourceware.cygnus.com Subject: Re: New stream - gdb_stdlog/gdb_stddebug? Date: Sat, 12 Jun 1999 18:45:00 -0000 Message-id: <376309F8.333D404D@cygnus.com> References: <376053FF.3050D846@cygnus.com> X-SW-Source: 1999-q2/msg00155.html Content-length: 639 Andrew Cagney wrote: > > Hello, > > At present GDB has two output streams: > > gdb_stdout > gdb_stderr > > I'd like to propose the addition of a third stream: > > gdb_stdlog OR gdb_stddebug > > that would be used by any debug/log messages. For the moment I've called it ``gdb_stdlog'' and added it to main.c At the same time I've updated (fixed I would argue :-) remote.c and gdbarch.c so that they send their trace/log messages to gdb_stdlog and not gdb_stdout. By default gdb_stdlog ends up in gdb_stdout so the TUI and normal users won't notice any difference. enjoy, Andrew >From robertl@sco.com Sat Jun 12 20:59:00 1999 From: Robert Lipe To: gdb@sourceware.cygnus.com Subject: dwarf-2 problem on cc1 Date: Sat, 12 Jun 1999 20:59:00 -0000 Message-id: <19990612225533.A22838@rjlhome.sco.com> X-SW-Source: 1999-q2/msg00156.html Content-length: 3019 ----- Transcript of session follows ----- 550 gdb@gdb.cygnus.com... Host unknown (Name server: gdb.cygnus.com.: host not found) [ Damned inconsistencies ] Date: Sat, 12 Jun 1999 20:00:46 -0500 From: Robert Lipe To: egcs@egcs.cygnus.com Cc: gdb@gdb.cygnus.com Subject: dwarf-2 problem on cc1 Message-ID: <19990612200046.A22605@rjlhome.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95us [ Two disparate groups copied; please drop the other as appropriate. ] I can't tell if this is an GCC problem or a GDB problem. I'm inclined to think it's EGCS becuase SCO's 'debug' complains about the binary, too. I'm looking at GCC 2.95 (i686-UnixWare7.1.0-sysv5) with GDB 4.18. Small binaries work OK. Big ones fail and I need help understanding why. The easiest way to see this fail is in GCC itself after a full three-stage: (robertl) rjludi:/home3/negcs/gcc $ gdb ./cc1 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-UnixWare7.1.0-sysv5"... Dwarf Error: bad offset (0x93000200) in compilation unit header (offset 0x2320b5 + 6). .gdbinit:8: Error in sourced command file: Now, if I use GDB on GDB to debug cc1 and set breakpoints on this error, I can see that it's not anything as "obvious" as a sign extension problem. (top-gdb) print /x cu_header $2 = {length = 0x28000000, version = 0x2, abbrev_offset = 0x93000200, addr_size = 0xce} That's a pretty bogus looking length. If I feed that same binary to the SCO dwarf-2 debugger, it complains in a different way: $ debug cc1 Error: Unrecognized debugging information at offset 0x2320b5 Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788 Error: Unrecognized debugging information at offset 0x2320b5 Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788 Error: Unrecognized debugging information at offset 0x2320b5 Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788 Error: Unrecognized debugging information at offset 0x2320b5 Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788 Error: Unrecognized debugging information at offset 0x2320b5 Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788 Error: Unimplemented DWARFII location operator at offset 0x5237: DW_OP_fbreg Error: Unimplemented DWARFII debugging information entry in section .debug_info New program cc1 (process p1) created It's not strictly size related. I can invoke gdb on cc1plus and it's fine. gdb on several of the gen* programs and it's fine. but the inability to debug cc1 worries me. Any ideas? RJL ----- End forwarded message ----- ----- End forwarded message ----- >From robertl@sco.com Sat Jun 12 21:49:00 1999 From: Robert Lipe To: egcs@egcs.cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: dwarf-2 problem on cc1 Date: Sat, 12 Jun 1999 21:49:00 -0000 Message-id: <19990612234841.A22906@rjlhome.sco.com> References: <19990612200046.A22605@rjlhome.sco.com> <19990612200046.A22605@rjlhome.sco.com> X-SW-Source: 1999-q2/msg00157.html Content-length: 1707 > I can't tell if this is an GCC problem or a GDB problem. I'm inclined > to think it's EGCS becuase SCO's 'debug' complains about the binary, too. GDB now seems to be off the hook here. > This GDB was configured as "i686-UnixWare7.1.0-sysv5"... > > Dwarf Error: bad offset (0x93000200) in compilation unit header > (offset 0x2320b5 + 6). The problem seems to be one of mixing UDK dot-oh's with EGCS ones. During the bootstrap the native compiler is used to build libiberty. All of the "offending" objects that I could find were in the libiberty directory. [ At one point, didn't we change the EGCS bootstrap to rebuild libiberty? ] Sure enough, if I blast libiberty and rebuild it with the freshly built GCC, and relink cc1 with that libiberty this issue goes away. It looks like someone still building configure's with an old version of autoconf that doesn't have the fix that rth donated earlier this year. So the libiberty that's being built has several .o's in it (like 'memset' and 'memcpy') that shouldn't even be there. Why aren't we using the fixed autoconf to generate correct configure scripts? I thought Ben got that fix into 2.13 but will check. The issue about compatibility with the native compilers is, I suppose, a completely different problem. (And one of lesser interest than the general "something is broken" case.) I now feel much better about the reliability of the dwarf generation and handling in EGCS and GDB for 2.95. ...now the issue of dwarf-1 or dwarf-2 even making it through a bootstrap comes to light. :-) RJL >From jtc@redback.com Mon Jun 14 16:14:00 1999 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: gdb@sourceware.cygnus.com Subject: Re: breakpoint extension for remote protocol, take II Date: Mon, 14 Jun 1999 16:14:00 -0000 Message-id: <5mzp222x5d.fsf@jtc.redbacknetworks.com> References: <375D205F.F191C5@cygnus.com> X-SW-Source: 1999-q2/msg00158.html Content-length: 3179 >>>>> "Andrew" == Andrew Cagney writes: Andrew> Have you considered what to do when there is a choice of Andrew> software breakpoints? Jim Ingham's pointed out to me that in Andrew> the case of the MIPS/MIPS16 and ARM/THUMB the breakpoint might Andrew> be 2 bytes or 4 bytes in size (and the value different in each Andrew> case). I was unaware processors with multiple software breakpoints existed. I assume that the 2 byte breakpoint instructions have to be inserted in "high-density" code segments and 4 byte breakpoints insns have to be inserted in "low-density" segments. We can almost get away without specifying breakpoint types. Since in most cases the stub is bound into the executable, thus can determine whether the breakpoint is within a high or low density code segment. However, this would not be suitable for applications like monitors with a remote protocol front end, as those would not have any prior knowledge of an arbitrary program's memory map. I was hoping to avoid exposing implementation details of breakpoints managed by this extension. This was intended to provide flexibility so that breakpoints could be implemented using mechanisms beyond what might be present in the CPU alone. For example, the stub could use a trap insn of some type instead of the traditional breakpoint insn, or use some hardware assistance (perhaps in a memory controller ASIC). As a result, although implementations could be quite different, GDB would neither know nor care. Andrew> For such targets, always sending the length would be easiest. Andrew> Can any one see problems with sending the length regardless? I was considering the possibility of interpreting the length field of software breakpoints so as to represent address ranges. The converse, a breakpoint that traps whenever the PC falls out of a range is probably more useful though. I'm also thinking of ideas of how to do more breakpoint processing in the stub. The obvious thing is thread specific breakpoints --- it is very inefficent for the target to stop and return control to GDB, for GDB to query the current thread and determine that the breakpoint is not appropriate, and then for GDB to continue execution. If the stub could determine the whether the breakpoint had really tripped, performance would be much improved. In fact, GDB may not need to be modified significantly. Since the breakpoint has fired and program state is going to be examined (either interactively or via a breakpoint command script), overhead of (re-) confirming that the breakpoint is either global or for the current thread should be negligable. This would also allow for "thinner" stub implement- ations that don't contain per-thread management of breakpoints if code size is more important than performance. Similarly, a simple (stack based?) scheme for evaluating conditional breakpoints could be created, although I suspect this would require significant changes to GDB internals. It might be useful to nail down (or at least think about) this even if it won't be implemented in the near term, so it can be cleanly added to the protocol. --jtc -- J.T. Conklin RedBack Networks >From ac131313@cygnus.com Mon Jun 14 16:35:00 1999 From: Andrew Cagney To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: breakpoint extension for remote protocol, take II Date: Mon, 14 Jun 1999 16:35:00 -0000 Message-id: <3765916E.2D458BAF@cygnus.com> References: <375D205F.F191C5@cygnus.com> <5mzp222x5d.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q2/msg00159.html Content-length: 1469 "J.T. Conklin" wrote: > > >>>>> "Andrew" == Andrew Cagney writes: > Andrew> Have you considered what to do when there is a choice of > Andrew> software breakpoints? Jim Ingham's pointed out to me that in > Andrew> the case of the MIPS/MIPS16 and ARM/THUMB the breakpoint might > Andrew> be 2 bytes or 4 bytes in size (and the value different in each > Andrew> case). > > I was unaware processors with multiple software breakpoints existed. > I assume that the 2 byte breakpoint instructions have to be inserted > in "high-density" code segments and 4 byte breakpoints insns have to > be inserted in "low-density" segments. > > We can almost get away without specifying breakpoint types. Since in > most cases the stub is bound into the executable, thus can determine > whether the breakpoint is within a high or low density code segment. > However, this would not be suitable for applications like monitors > with a remote protocol front end, as those would not have any prior > knowledge of an arbitrary program's memory map. FYI, I can't see how a stub can determine the breakpoint size/type from just the address. As it is GDB has enough trouble - in the case of the ARM, GDB ends up using symbol table information. I've also been doing some research into the ``B'' and ``b'' packets. While the stubs found in gdb/*stub.c don't support ``b'' or any other ``B'' packet there are other stubs (non GPL'd) that do reconize it :-( Andrew >From sethnaz@sg.adi-limited.com.au Mon Jun 14 16:47:00 1999 From: Zubin Burjor Sethna To: gdb@sourceware.cygnus.com Subject: gdb + wiggler Date: Mon, 14 Jun 1999 16:47:00 -0000 Message-id: <6006B52C37ABD211AB0900805FFE9D7916933C@exchange.sg.adisys.com.au> X-SW-Source: 1999-q2/msg00160.html Content-length: 323 Hi Has anyone had any success using the gdb from the ecos tool chain with a wiggler? A wiggler is a debugging interface for BDM and the target I am using is MPC860? I tried the wiggler support in the ecos gdb but all I got were core dumps. Do I need any additonal drivers than what is supplied with gdb? Thanks Zubin