From mboxrd@z Thu Jan 1 00:00:00 1970 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:48:00 -0000 Message-id: <5mwvx62vl7.fsf@jtc.redbacknetworks.com> References: <375D205F.F191C5@cygnus.com> <5mzp222x5d.fsf@jtc.redbacknetworks.com> <3765916E.2D458BAF@cygnus.com> X-SW-Source: 1999-q2/msg00161.html >>>>> "Andrew" == Andrew Cagney writes: >> 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. Andrew> FYI, I can't see how a stub can determine the breakpoint Andrew> size/type from just the address. As it is GDB has enough Andrew> trouble - in the case of the ARM, GDB ends up using symbol Andrew> table information. I was thinking of a situation where the linker script adds special symbols at the beginning and end of the high and low density code segments, and the stub compares the breakpoint address with those symbols. This will work in a self contained executable, but not if any code is loaded dynamically. Andrew> I've also been doing some research into the ``B'' and ``b'' Andrew> packets. While the stubs found in gdb/*stub.c don't support Andrew> ``b'' or any other ``B'' packet there are other stubs (non Andrew> GPL'd) that do reconize it :-( Bleh. But that's what the 'q' escape is for. IMO, all experimental protocol extensions should be using 'q'; likewise, GDB should never use 'q' itself. But since GDB uses 'q', a stub using 'B' or 'b' is not surprising. --jtc -- J.T. Conklin RedBack Networks >From shebs@cygnus.com Mon Jun 14 16:51:00 1999 From: Stan Shebs To: gdb@sourceware.cygnus.com Subject: Testsuite Organization Proposal Date: Mon, 14 Jun 1999 16:51:00 -0000 Message-id: <199906142351.QAA06182@andros.cygnus.com> X-SW-Source: 1999-q2/msg00162.html Content-length: 1701 I'd like to propose a semi-formalization of the current testsuite organization, basically just reflecting current practice, but with enough precision to guide further additions. The testsuite is key for GDB developers; the breadth of functionality and platforms is now so broad, in many cases, users won't discover regressions for months or years after the change that caused them; while a testsuite run often reveals mistakes right away. First of all, testsuite organization mainly serves the purpose of intelligibility; DejaGNU finds all the expect scripts wherever they're placed. But with around 6000 tests in all, it becomes important to organize them sensibly. gdb.base This is the base testsuite. The tests in it should apply to all configurations of GDB (but generic native-only tests may live here). The test programs should be in a subset of C that is valid K&R, ANSI/ISO, and C++ (ifdefs are allowed). gdb. Language-specific tests for all languages besides C. gdb. Non-portable tests. The tests are specific to a specific configuration (host or target), such as HP-UX or eCos. gdb. Tests specific to a particular compiler. There aren't currently any groups of tests in this category that couldn't just as sensibly be made platform-specific, but one could imagine a gdb.gcc, for tests of GDB's handling of GCC extensions. gdb. Tests that exercise a specific subsystem in more depth. For instance, gdb.disasm exercises various disassemblers, while gdb.stabs tests pathways through the stabs reader. Please feel free to comment on this. If everybody thinks this is great, I'll add to the internals manual. Stan >From shebs@cygnus.com Mon Jun 14 16:59:00 1999 From: Stan Shebs To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: breakpoint extension for remote protocol, take II Date: Mon, 14 Jun 1999 16:59:00 -0000 Message-id: <199906142359.QAA06291@andros.cygnus.com> References: <5mwvx62vl7.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q2/msg00163.html Content-length: 777 Date: 14 Jun 1999 16:47:32 -0700 Lines: 39 Bleh. But that's what the 'q' escape is for. IMO, all experimental protocol extensions should be using 'q'; likewise, GDB should never use 'q' itself. You mean like with qOffsets, that's been standardly issued by GDB for years? :-) Actually, I don't ever remember hearing that 'q' was supposed to be experimental, and the existing docs don't seem to say so either. At this point we would have to pick a different char I think, and be very disciplined about not allowing any usages of it into the standard sources, so that it really can be for experimentation. In general, we have a sizeable documentation gap with the remote protocol; it's become so ubiquitous it ought to have its own RFC... :-) Stan