From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Edwards To: Fernando Nasser Cc: gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000222102202.A6464@visi.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> X-SW-Source: 2000-q1/msg00370.html On Tue, Feb 22, 2000 at 03:36:52PM +0000, Fernando Nasser wrote: > > The RDI target support seems to be broken in the 000215 > > snapshot. I'm unable to execute any of the eCos test programs, > > or any other applictions I've written. (they run fine with a > > patched-up 4.18 gdb). I don't know what's wrong with it and > > won't have time to look at it for a while. > > Can you be more specific? It is working right with the AEB board and > with another one I have here. Both use serial ports. I tried it using the ARM Embedded ICE with serial-only and with serial-parallel interfaces. It connects to the device OK, and I can load a file and set breakpoints, but when I type "cont", gdb just hangs. Ctrl-C doesn't get any response, and I have to suspend and then kill gdb. (This usually means that gdb is waiting for a response from the JTAG interface box, and it isn't sending anything.) The exact same sequence of operations w/ patched 4.18 works (the program runs properly, hits the expected breakpoint, etc.). I haven't tried it with the EPI Jeeni. I plan on comparing ADP packet logs to see what is different, but this week is pretty busy and next week I'm going to be at the Embedded Systems Conference in Chicago. So I won't get a chance to play with it for a couple weeks. > Please let me know what is your host machine, what version of > tools did you use to build gdb, if on cygwin, which version of > the dll and, last but not least, what is it that you are > getting on the console. Host: Linux-Intel (Vanilla RH6.1 w/ 2.2.12-20 kernel) Gcc: egcs-2.91.66 (came w/ RH6.1) > > Is somebody currently working on the RDI code? If so, I'll > > leave well enough alone until the code stabilizes. > > > The usual folks. You, myself, Thomas, Nick, Jim... and I build and > test it at least twice a week. Odd. The ADP protocol/code from ARM is pretty fragile. If the target doesn't reply to a command, the whole thing sits there and you have to kill gdb, reset the target, and start over. Onee could add a receive timeout, but it won't do any good if the JTAG interface box is hung. There's also the problem of the two ends of the ADP connection getting frame sequence numbers out of sync -- so there may not be a practical solution other that the current "reset both ends and start over" approach. -- Grant Edwards grante@visi.com >From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: gdb@sourceware.cygnus.com Subject: Re: So who maintains the web pages? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <38A60492.2BB9E437@cygnus.com> X-SW-Source: 2000-q1/msg00252.html Content-length: 277 > As for what to put in MAINTAINERS, how about "anyone listed in this > file (in any section) may have write-without-approval . . . Oh, and if you want someone to be the "lead maintainer" or "lead victim" or some such concept for the web pages, feel free to put me down. >From taylor@cygnus.com Sat Apr 01 00:00:00 2000 From: David Taylor To: Pierre Muller Cc: gdb@sourceware.cygnus.com Subject: Re: Status of submitted patches? Pascal language addition patch. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002011920.OAA02797@texas.cygnus.com> X-SW-Source: 2000-q1/msg00087.html Content-length: 671 From: Pierre Muller Date: Tue, 01 Feb 2000 18:02:13 +0100 I submitted a big patch for adding Pascal Language support in GDB already 1999/10/22. I'm afraid that I don't remember much about the patch; nor do I have a copy of it stashed away. Small patches are better than big patches. The larger the patch the longer it takes to read and evaluate -- and it is definitely non linear. Up to a point it seems to be roughly quadratic -- double the size of the patch and it takes maybe four times longer to understand it. Please resubmit the patch (against a recent snapshot) and we'll try to do better this time around. >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: blizzard@mozilla.org Cc: gdb@sourceware.cygnus.com Subject: Re: problems with gdb Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002121759.e1CHxMG02867@delius.kettenis.local> References: <38A47E89.3F4674B3@mozilla.org> X-SW-Source: 2000-q1/msg00244.html Content-length: 5673 Date: Fri, 11 Feb 2000 16:26:33 -0500 From: Chris Blizzard Hi, folks. I've been talking about some problems that I've been suffering through with gdb and mozilla which people on this mailing list may or may not be aware of. Jason Molenda suggested that I start flushing these out in the open to get some feedback on them. I'm interested in getting my hands dirty and try to get these problems fixed. I'm not a debugger hacker though so I might end up asking some silly questions. :) No problem! May I ask some questions first? What version of GDB are you using? What version of GCC are you using? Here's the blurb, slightly edited for content. ...My problems are mostly related to how well gdb scales to handle large shared libraries and large numbers of shared libraries. At last count, there were 111 .so files in mozilla, the largest of which is about 27 meg with debugging symbols. If you don't use "set auto-solib-add 0" in your .gdbinit file, gdb will easily grow to over 200 meg in size when starting the debugger. Someone once did some estimates and it seems to use 5 times the size of a .so after loading a shared library to debug. A lot of times, gdb won't be able to load some of the larger .so files. It just hangs. Let me first say that Mozilla seems to stretch things to the limit. The huge number of shared libraries that you guys are using have already uncovered several bugs in the dynamic linker and the Mozilla developers have uncovered more than a few bugs in the LinuxThreads library. That's mostly because you have gone where no one's gone before :-) >From a quick glance at the output of `ps' on my system when loading a program that uses about 10 shared libraries it seems that the GDB memory usage is aproximately equal to the size of the shraed libraries on disk. I guess the "factor 5" estimate, is referring to the space used for debugging symbols as compared to the actual code-size of the shared library. So it seems that your biggest problem is the size of your shared libraries and the amount of debugging information that's generated (which is basically proportional to the amount of code in the libraries). I think that using C++ is in a large way responsible for the `code bloat'. Maybe an intelligent use of C++ features (check for compiler switches like -fno-rtti and use them if appropriate) can reduce the size of the resulting code. Also playing around with the options that control the way debugging information is generated might help. In principle the large amounts of debugging info shouldn't be a problem. GDB can simply mmap the relevant sections, such that only the debugging info that's really needed is actually pages in. I don't know how the BFD library (the part of GDB that is responsible for reading the sections containing debugging info) and the code that that actually interprets this information implements these things. There might be room for improvement there. Of course if all pages containing debugging info are touched, you lose :-(. A lot of times, trying to use "step" to step into a c++ method that happens to be part of the same class just skips as if you had used "next." That means that any time you want to step into a method you have to set a temporary breakpoint by name on the method and then allow the breakpoint to get you into that method. Doing that to step into a dozen or so classes gets a little tedious. This is hard to reproduce and I'm trying to build a test case. It is a known problem that GDB has problems with the debugging output generated by recent GCC compilers. Help in resolving those problems would certainly be appreciated, and a (small) test case is really essential if you want to get somebody else to look into it. Compiling without optimization might circumvent these problems. There are other much needed features, like not being able to preload a .so and setting a breakpoint in the library before it loads. Mozilla is entirely component based and this makes debugging very, very difficult. I usually break on _dl_open in glibc and wait until my library gets loaded before trying to set the breakpoint that I need. That gets pretty bad after 27 libraries are loaded. I think that the way GDB looks up symbols is differs from the way the dynamic linker does that. That means that overriding symbols in shared libraries probably doesn't work properly. Since the primary use of preloaded shared libraries is overriding symbols you're likely to experience problems. I don't think this problem is easy to solve. Setting breakpoints in not-yet loaded shared libraries should not be difficult to implement. Just make sure they start out as `shlib_disabled' (see breakpoint.h) if the symbol cannot be found. It is necessary to introduce a new command to do this (suggested name `shlib-break' or `solib-break'). Reusing the guts of the ordinary breakpoint setting command should be possible. There are also various problems with threads. A lot of times gdb won't exit after the last thread exits because it keeps trying to kill a process which doesn't exist any more. Probably caused by the strange way threads interact with signals on Linux. It's very likely that the real bug is in the LinuxThreads library and not in GDB. A lot of LinuxThreads problems have recently been solved. You might want to try the latest glibc 2.1.3 pre-release. Or have a little patience, glibc 2.1.3 is supposed to be released real soon now. Hope this helps, and I'm looking forward to your contributions :-), Mark >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Jonathan Larmour Cc: gdb@sourceware.cygnus.com Subject: Re: copyright banner and reporting bugs Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38DF418A.42355DAD@cygnus.com> References: <38CFF922.6BA6928E@redhat.co.uk> X-SW-Source: 2000-q1/msg00817.html Content-length: 547 Jonathan Larmour wrote: > > I just noticed two minor things: surely the copyright banner when GDB starts > should be something more recent than 1998 even now - i.e. it shouldn't need > to wait for the release. Good point. It should pick up Makefile.in:VERSION. > Also on http://sourceware.cygnus.com/gdb it isn't at all clear how users > report bugs. This is worthy of a section in its own right surely! Just an > appropriate regurgitation of the info file node from gdb.texinfo would be > enough. I've updated it. Feedback welcome. Andrew >From velco@fadata.bg Sat Apr 01 00:00:00 2000 From: Momchil Velikov To: GDB List Subject: Remote debugging over UDP Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38DFABC7.A884D5D7@fadata.bg> X-SW-Source: 2000-q1/msg00825.html Content-length: 362 Hi, I have added support for debugging remote targets over UDP ("added support", that's cloned ser-tcp.c and tweaked it a little bit). Are interested in including that in GDB ? Do you mind changing the syntax the parameter NAME to serial.c:serial_open () to tcp::, and udp:: for TCP and UDP connections, respectively ? Regards, -velco >From toddpw@windriver.com Sat Apr 01 00:00:00 2000 From: Todd Whitesel To: kingdon@redhat.com (Jim Kingdon) Cc: akale@veritas.com, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Regression caused by elfread.c patch Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002150800.AAA07477@alabama.wrs.com> References: <200002150453.XAA11268@devserv.devel.redhat.com> X-SW-Source: 2000-q1/msg00289.html Content-length: 1928 > I don't see how your patch could work at all - sym->section->index is > a very different number than a SECT_OFF_* code. The SECT_OFF_* code In case it interests anyone, I spent most of January figuring out how to teach GDB how to let both cases coexist properly. It is my considered opinion that the SECT_OFF_* machinery really only works when all the offsets are the same. However, so few configurations (read: vxWorks and ??) actually use different offsets for, say, SECT_OFF_TEXT and SECT_OFF_DATA, that no one notices the problems with it. (We read relocatable .o files too, which is also rare.) Our particular bug is as follows: for a.out, read-only data gets put into .text, but the stabs generated are indistinguishable (or prohibitively hard to distinguish, anyway) from a non-const version of the same item which gets put into .data. Thus it is impossible to find the correct address without using actual relocation records. (The same bug occurs on ELF although in this case it is because .rodata is classed as a text section by our loader, which then feeds us a single address for the group of text sections. sigh) One of our consultants developed code for ELF/DWARF relocatables which actually calls bfd_final_link_relocate to process reloc info, because in the DWARF case we have even less information to tell things apart than with stabs. I extended that to do full final address relocation and worked out how to have struct section_offsets keep track of what is going on, so that ANOFFSET can be replaced with a variety of different macros depending on what usage is intended. (This also allowed optional asserts to be compiled in, which turned out to be helpful once I started testing, and illuminated a few cases too.) A gutted tarball of 4.17+local sources is temporarily available (in an execute-only directory) at: ftp://ftp.toddpw.org/private/vxgdb.tar.bz2 -- Todd Whitesel toddpw @ windriver.com >From davea@dsl-quasar.corp.sgi.com Sat Apr 01 00:00:00 2000 From: davea@dsl-quasar.corp.sgi.com (David B. Anderson) To: gdb@sourceware.cygnus.com Subject: Re: mdebug Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003312258.OAA25181@dsl-quasar.corp.sgi.com> X-SW-Source: 2000-q1/msg00847.html Content-length: 1092 Elena Zannoni writes: >Does anybody know something about mdebug? Yes. >I am trying to figure out a problem in gdb which untilmately is due >to some limitation of mdebug. >Is there any documentation at all about how the debug symbols are built? http://reality.sgi.com/davea/objectinfo.html Look early in the page for: one part of the old 32bit ABI for MIPS is the mdebug debugging information. A postscript file with the only currently available description of this data is here (119Kbytes) It is is an old paper I wrote on mdebug. Not too well written, but... what else is there? Perhaps it will help. Does not mention limits, though. The limits are implicit in various structs. Perhaps 'explicit' is a better word :-) If you have any questions let me know. (whether I'll know the answer is something else...) I don't know too much about DEC or other *extensions* to mdebug. Just sgi's. But there are certainly some important limitations in mdebug. Like 64K procedures (at most). SGI did some hack extensions, but ... never mind. davea@sgi.com >From srikanth@cup.hp.com Sat Apr 01 00:00:00 2000 From: Srikanth To: Chris Blizzard Cc: gdb@sourceware.cygnus.com Subject: Re: problems with gdb Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38AB3457.6902@cup.hp.com> References: <38A47E89.3F4674B3@mozilla.org> <38AB2DC4.FA9A3C71@redhat.com> X-SW-Source: 2000-q1/msg00315.html Content-length: 4577 Chris Blizzard wrote: > > So, one of the problems that I've been having is that some large .so libraries > take forever to load. One of the libraries is about 28 meg with debugging > symbols in it. I've let it run for about 10 mins and it's never finished > loading. Here's what gprof says for loading a reasonable sized library ( 5 > meg or so ): > > Flat profile: > > Each sample counts as 0.01 seconds. > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 70.98 19.47 19.47 11954 1.63 2.25 lookup_minimal_symbol > 27.12 26.91 7.44 33240213 0.00 0.00 strcmp_iw > 0.33 27.00 0.09 3 30.00 9038.95 read_dbx_symtab > 0.15 27.04 0.04 44554 0.00 0.00 hash > 0.11 27.07 0.03 337915 0.00 0.00 bfd_getl32 > 0.11 27.10 0.03 44554 0.00 0.00 bcache > 0.11 27.13 0.03 150 0.20 0.20 end_psymtab > > Uhh...that's 33 _million_ calls. That looks like this chunk of code: > > for (objfile = object_files; > objfile != NULL && found_symbol == NULL; > objfile = objfile->next) > { > if (objf == NULL || objf == objfile) > { > for (msymbol = objfile->msymbols; > msymbol != NULL && SYMBOL_NAME (msymbol) != NULL && > found_symbol == NULL; > msymbol++) > { > if (SYMBOL_MATCHES_NAME (msymbol, name)) > { > switch (MSYMBOL_TYPE (msymbol)) > { > case mst_file_text: > > I'm sorry, is that looking over a linked list? SYMBOL_MATCHES_NAME() is a > macro that does some mangling magic so we can't use a standard hash lookup > table but there has to be something we can do to speed that up. > > --Chris > We at HP have been running into many of these issues and have substantially re-architected the symbol table management to achieve performance. Here are some of the things we did : (1) The function lookup_minimal_symbol believe it or not performs linear search. The minimal symbol table is sorted by the symbol address and not by name, so binary searches are possible in lookup_minimal_symbol_by_pc but not in lookup_minimal_symbol () The difficulty here is that a name lookup could be based on either a demangled name or a mangled name. So unless we sort the table by both we will have to do linear search. Sorting the table by both involves heavy penalty at startup, as that entail three sorts with different keys (PC, demangled name and mangled name). We eliminated one of the keys : the demangled name and do a double sort. (2) Just in time demangling : Rightnow, gdb demangles the linker symbol table at startup. This simply does not scale well to large applications. We implemented a scheme by which we eliminate all anticipatory demangling and do it just in time, only for the set of symbols the user refers to in a debugging session. Other than the "minimal" symbol table, there could be other spots where whole scale anticipatory demangling could be going on : in build_psymtabs() etc ... Avoiding anticipatory demangling allowed us to eliminate one of the sort keys for (1) above. This may or may not be possible to do with your compiler. (3) GDB internalizes the native debugging information in its entirety. Studies show a "typical" debugging session uses less than 15% all debug info from a binary. (4) For C++, it is very likely the linker (minimal) symbol table contains all kinds of compiler generated symbols for such things like vtables, exception handling, RTTI etc. Also based on your compiler, last of internal symbols generated for the purpose of relocation could be making their way into the linker symbol table. Do a maint print msymbols and take a look for symbols that don't look like user space symbols. Some of these symbols are crucial for gdb ro interact properly with the runtime. But there could be others.... (5) The bcache could be extremely expensive in some platforms. What this module does is to try to eliminate duplicates in debug info. Some platforms (like HP) eliminate all (most) redundancy in the debug info in a hidden linker pass. For HP we simply disconnected the bcache and saw a 50% improvement in memory and 20% or so performance improvement. (6) Compilers could be emitting too much debug info than is necessary. Some compilers try to be optimal but some don't. Hope this is helpful. Srikanth >From msnyder@cygnus.com Sat Apr 01 00:00:00 2000 From: Michael Snyder To: Andrew Cagney Cc: dan@cgsoftware.com, Mark Kettenis , gdb@sourceware.cygnus.com, drepper@cygnus.com Subject: Re: lin-thread cannot handle thread exit Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38CEE0DD.11A@cygnus.com> References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com> <38C7EDFB.7457@cygnus.com> <38CDEDC5.4107034@cygnus.com> <38CE81B2.9CA@cygnus.com> <38CEDB3E.DA17FA9A@cygnus.com> X-SW-Source: 2000-q1/msg00705.html Content-length: 472 Andrew Cagney wrote: > > Michael Snyder wrote: > > > As far as I can tell, yes it did. > > This is something that the thread_db implementation was > > designed to handle -- I just didn't get around to it. > > I hope to be able to fit it in "real soon now". > > So this effectivly means that this particular thread problem is a ``nice > to have'' rather than a ``must have'' for 5.0. > > Something that can be better easier fixed in the 5.1 timeframe. I would say so. >From jtc@redback.com Sat Apr 01 00:00:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: Re: memory region attribute CLI Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5m3dplwjri.fsf@jtc.redbacknetworks.com> References: <5mr9dd5dlt.fsf@jtc.redbacknetworks.com> <200003160944.EAA01842@indy.delorie.com> <5mem9avs45.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00745.html Content-length: 11575 >>>>> "jtc" == J T Conklin writes: jtc> Yes, I guess it has been a while, hasn't it. jtc> jtc> Start at: jtc> http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00168.html No comments? Here's a bit more meat. I've gone ahead and implemented the CLI, and would appreciate any comments. I'm planning on writing documentation and making the changes to use these attributes this week. Many thanks, --jtc /* memattr.h */ #ifndef MEMATTR_H #define MEMATTR_H /* FIXME: I stole this bit from tracepoint.h. The definition should probably be moved out of breakpoint.h, tracepoint.h, and memattr.h and into defs.h or something like that. */ #if !defined (BREAKPOINT_H) enum enable { disabled, enabled }; #endif enum mem_access_mode { MEM_RW, /* read/write */ MEM_RO, /* read only */ MEM_WO, /* write only */ }; enum mem_access_width { MEM_WIDTH_UNSPECIFIED, MEM_WIDTH_8, /* 8 bit accesses */ MEM_WIDTH_16, /* 16 " " */ MEM_WIDTH_32, /* 32 " " */ MEM_WIDTH_64 /* 64 " " */ }; /* The set of all attributes that can be set for a memory region. This structure was created so that memory attributes can be passed to target_ functions without exposing the details of memory region list, which would be necessary if these fields were simply added to the mem_region structure. FIXME: It would be useful if there was a mechanism for targets to add their own attributes. For example, the number of wait states. */ struct mem_attrib { /* read/write, read-only, or write-only */ enum mem_access_mode mode; enum mem_access_width width; /* enables hardware breakpoints */ int hwbreak; /* enables host-side caching of memory region data */ int cache; /* enables memory verification. after a write, memory is re-read to verify that the write was successful. */ int verify; }; struct mem_region { /* FIXME: memory regions are stored in an unsorted singly-linked list. This probably won't scale to handle hundreds of memory regions --- that many could be needed to describe the allowed access modes for memory mapped i/o device registers. */ struct mem_region *next; CORE_ADDR lo; CORE_ADDR hi; /* Item number of this memory region. */ int number; /* Status of this memory region (enabled or disabled) */ int status; /* Attributes for this region */ struct mem_attrib attrib; }; extern struct mem_region *lookup_mem_region(CORE_ADDR); #endif /* MEMATTR_H */ /* memattr.c */ #include "defs.h" #include "command.h" #include "gdbcmd.h" #include "memattr.h" #include "gdb_string.h" const struct mem_attrib default_mem_attrib = { MEM_RW, /* mode */ MEM_WIDTH_UNSPECIFIED, false, /* hwbreak */ false, /* cache */ false /* verify */ }; static struct mem_region *mem_region_chain = NULL; static mem_number = 0; static struct mem_region * create_mem_region (CORE_ADDR lo, CORE_ADDR hi, const struct mem_attrib *attrib) { struct mem_region *n, *p, *new; if (lo > hi) { printf_unfiltered ("invalid memory region\n"); return NULL; } n = mem_region_chain; while (n) { /* overlapping node */ if ((lo >= n->lo && lo <= n->hi) || (hi >= n->lo && hi <= n->hi)) { printf_unfiltered ("overlapping memory region\n"); return NULL; } } new = xmalloc (sizeof (struct mem_region)); new->lo = lo; new->hi = hi; new->number = ++mem_number; new->status = enabled; new->attrib = *attrib; /* link in new node */ new->next = mem_region_chain; mem_region_chain = new; return new; } static void delete_mem_region(struct mem_region *m) { free(m); } struct mem_region * lookup_mem_region(CORE_ADDR addr) { struct mem_region *m; for (m = mem_region_chain; m; m = m->next) { if (addr >= m->lo && addr <= m->hi) return m; } return NULL; } static void mem_command (char *args, int from_tty) { CORE_ADDR lo, hi; char *tok; struct mem_attrib attrib; if (!args) error_no_arg("No mem"); tok = strtok(args, " \t"); if (!tok) error("no lo address"); lo = parse_and_eval_address(tok); tok = strtok(NULL, " \t"); if (!tok) error("no hi address"); hi = parse_and_eval_address(tok); attrib = default_mem_attrib; while ((tok = strtok (NULL, " \t")) != NULL) { if (strcmp (tok, "rw") == 0) attrib.mode = MEM_RW; else if (strcmp (tok, "ro") == 0) attrib.mode = MEM_RO; else if (strcmp (tok, "wo") == 0) attrib.mode = MEM_WO; else if (strcmp (tok, "8") == 0) attrib.width = MEM_WIDTH_8; else if (strcmp (tok, "16") == 0) { if ((lo % 2 != 0) || (hi % 2 != 0)) error ("region bounds not 16 bit aligned"); attrib.width = MEM_WIDTH_16; } else if (strcmp (tok, "32") == 0) { if ((lo % 4 != 0) || (hi % 4 != 0)) error ("region bounds not 32 bit aligned"); attrib.width = MEM_WIDTH_32; } else if (strcmp (tok, "64") == 0) { if ((lo % 8 != 0) || (hi % 8 != 0)) error ("region bounds not 64 bit aligned"); attrib.width = MEM_WIDTH_64; } else if (strcmp (tok, "hwbreak") == 0) attrib.hwbreak = true; else if (strcmp (tok, "swbreak") == 0) attrib.hwbreak = false; else if (strcmp (tok, "cache") == 0) attrib.cache = true; else if (strcmp (tok, "nocache") == 0) attrib.cache = false; else if (strcmp (tok, "verify") == 0) attrib.verify = true; else if (strcmp (tok, "noverify") == 0) attrib.verify = false; else error ("unknown attribute: %s", tok); } create_mem_region(lo, hi, &attrib); } static void mem_info_command (char *args, int from_tty) { struct mem_region *m; struct mem_attrib *attrib; if (!mem_region_chain) { printf_unfiltered ("There are no memory regions defined.\n"); return; } printf_filtered ("Memory regions now in effect:\n"); for (m = mem_region_chain; m; m = m->next) { printf_filtered ("%d: %c\t", m->number, m->status ? 'y' : 'n'); printf_filtered ("%s - ", local_hex_string_custom ((unsigned long) m->lo, "08l")); printf_filtered ("%s\t", local_hex_string_custom ((unsigned long) m->hi, "08l")); /* Print a token for each attribute. * * FIXME: Should we output a comma after each token? It may * make it easier for users to read, but we'd lose the ability * to cut-and-paste the list of attributes when defining a new * region. Perhaps that is not important. * * FIXME: If more attributes are added to GDB, the output may * become cluttered and difficult for users to read. At that * time, we may want to consider printing tokens only if they * are different from the default attribute. */ attrib = &m->attrib; switch (attrib->mode) { case MEM_RW: printf_filtered ("rw "); break; case MEM_RO: printf_filtered ("ro "); break; case MEM_WO: printf_filtered ("wo "); break; } switch (attrib->width) { case MEM_WIDTH_8: printf_filtered ("8 "); break; case MEM_WIDTH_16: printf_filtered ("16 "); break; case MEM_WIDTH_32: printf_filtered ("32 "); break; case MEM_WIDTH_64: printf_filtered ("64 "); break; case MEM_WIDTH_UNSPECIFIED: break; } if (attrib->hwbreak) printf_filtered ("hwbreak"); else printf_filtered ("swbreak"); if (attrib->cache) printf_filtered ("cache "); else printf_filtered ("nocache "); if (attrib->verify) printf_filtered ("verify "); else printf_filtered ("noverify "); printf_filtered ("\n"); gdb_flush (gdb_stdout); } } /* Enable the memory region number NUM. */ static void mem_enable (int num) { struct mem_region *m; for (m = mem_region_chain; m; m = m->next) if (m->number == num) { m->status = enabled; return; } printf_unfiltered ("No memory region number %d.\n", num); } static void mem_enable_command (char *args, int from_tty) { char *p = args; char *p1; int num; struct mem_region *m; if (p == 0) { for (m = mem_region_chain; m; m = m->next) m->status = enabled; } else while (*p) { p1 = p; while (*p1 >= '0' && *p1 <= '9') p1++; if (*p1 && *p1 != ' ' && *p1 != '\t') error ("Arguments must be memory region numbers."); num = atoi (p); mem_enable (num); p = p1; while (*p == ' ' || *p == '\t') p++; } } /* Disable the memory region number NUM. */ static void mem_disable (int num) { struct mem_region *m; for (m = mem_region_chain; m; m = m->next) if (m->number == num) { m->status = disabled; return; } printf_unfiltered ("No memory region number %d.\n", num); } static void mem_disable_command (char *args, int from_tty) { char *p = args; char *p1; int num; struct mem_region *m; if (p == 0) { for (m = mem_region_chain; m; m = m->next) m->status = disabled; } else while (*p) { p1 = p; while (*p1 >= '0' && *p1 <= '9') p1++; if (*p1 && *p1 != ' ' && *p1 != '\t') error ("Arguments must be memory region numbers."); num = atoi (p); mem_disable (num); p = p1; while (*p == ' ' || *p == '\t') p++; } } /* Clear memory region list */ static void mem_clear (void) { struct mem_region *m; while ((m = mem_region_chain) != 0) { mem_region_chain = m->next; delete_mem_region(m); } } /* Delete the memory region number NUM. */ static void mem_delete(int num) { struct mem_region *m1, *m; if (!mem_region_chain) printf_unfiltered ("No memory region number %d.\n", num); if (mem_region_chain->number == num) { m1 = mem_region_chain; mem_region_chain = m1->next; delete_mem_region(m1); } else for (m = mem_region_chain; m->next; m = m->next) { if (m->next->number == num) { m1 = m->next; m->next = m1->next; delete_mem_region(m1); break; } } printf_unfiltered ("No memory region number %d.\n", num); } static void mem_delete_command (char *args, int from_tty) { char *p = args; char *p1; int num; if (p == 0) { if (query ("Delete all memory regions? ")) mem_clear(); dont_repeat(); return; } while (*p) { p1 = p; while (*p1 >= '0' && *p1 <= '9') p1++; if (*p1 && *p1 != ' ' && *p1 != '\t') error ("Arguments must be memory region numbers."); num = atoi (p); mem_delete (num); p = p1; while (*p == ' ' || *p == '\t') p++; } dont_repeat(); } _initialize_mem () { add_com ("mem", class_vars, mem_command, "Define attributes for memory region."); add_cmd ("mem", class_vars, mem_enable_command, "Enable memory region.\n\ Arguments are the code numbers of the memory regions to enable.\n\ Do \"info mem\" to see current list of code numbers.", &enablelist); add_cmd ("mem", class_vars, mem_disable_command, "Disable memory region.\n\ Arguments are the code numbers of the memory regions to disable.\n\ Do \"info mem\" to see current list of code numbers.", &disablelist); add_cmd ("mem", class_vars, mem_delete_command, "Delete memory region.\n\ Arguments are the code numbers of the memory regions to delete.\n\ Do \"info mem\" to see current list of code numbers.", &deletelist); add_info ("mem", mem_info_command, "Memory region attributes"); } -- J.T. Conklin RedBack Networks >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Robert Lipe Cc: gdb@sourceware.cygnus.com Subject: Re: config.guess version regression Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38B31515.73EA86EB@cygnus.com> References: <20000222151535.A23483@rjlhome.sco.com> X-SW-Source: 2000-q1/msg00374.html Content-length: 1060 Robert Lipe wrote: > > I suspect this is a result of the repository shuffling in recent weeks, > but the top-level config.guess went back several versions. This means > that some later OSes (i586-sco-sysv5uw7.1.1 in my case) is no longer > automatically recognized. FYI, getting config.guess updated is on my 5.0 hit list. > Should I submit an explicit patch to resync it against the one in > autoconf or can someone with CVS accesses to both just plunk a new > version in? If this is considered too radical, I suppose we can fish > for the config.guess that lived in gdb before the big restructuring. I'ts not at all radical :-) I've already done a heads up on the binutils side. I've just got to push the keys :-) Franz Sirl wrote: > Please don't sync with autoconf, it's currently outdated. Either sync with the > master repository "cvs -d :pserver:anoncvs@subversions.gnu.org:/home/cvs > co config" or use the one in GCC, which I synced last week. Ah, and don't > forget to sync both config.guess and config.sub. thanks for this pointer Andrew >From dan@cgsoftware.com Sat Apr 01 00:00:00 2000 From: Daniel Berlin To: gdb@sourceware.cygnus.com Subject: RTTI working for G++ Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: X-SW-Source: 2000-q1/msg00692.html Content-length: 3476 Okay, i have RTTI working for g++. Well, all except for multiple inheritance. Scratch that last part, i just made it offset properly if you have >1 baseclass, so al is good. If i could have one or two volunteers to make sure it's not just my setup, and that all is well, before i post the patches asking for comments, i'd appreciate it. In any case, let me know what you guys think of it so far. If you look at the output, you'll notice that while for printing, it will print the object as if it was it's derived type, when it comes to accessing members/methods, just like in C++, you can't access the members, unless you specifically cast it to that derived type. For those wondering what the patch will do, check this out: The inheritance on these classes in the example looks like this fred is a base dan and bob both inherit directly from fred. george is another base. george2 inherits from george and bob (public george, public bob) I'll rename them so they make more sense as i work up testcases. But anyway, here's some output: GNU gdb 20000204 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 "i386-unknown-freebsdelf4.0". Setting up the environment for debugging gdb. .gdbinit:5: Error in sourced command file: No symbol table is loaded. Use the "file" command. (gdb) file a.out Reading symbols from a.out...done. (gdb) b main Breakpoint 1 at 0x8048918: file a.cc, line 29. (gdb) set print object on (gdb) set print pretty on (gdb) set print vtbl on (gdb) set print array on (gdb) r Starting program: /usr/local/gdb/src/gdb/a.out Breakpoint 1, 0x8048918 in main () at a.cc:29 29 { (gdb) n 31 dan=new daniel(); (gdb) n 32 cout < = { a = 0, _vptr$ = 0x804f390 }, members of daniel: b = 0 } (gdb) ptype dan type = class fred { public: int a; fred & operator=(fred const &); fred(fred const &); fred(void); virtual int ab(void); } * (gdb) p dan[0]->b There is no member or method named b. (gdb) n 6daniel 33 dan=new bob(); (gdb) 34 dan=new george2(); (gdb) p dan $3 = (bob *) 0x8051040 (gdb) p dan[0] $4 = (bob) { = { a = 0, _vptr$ = 0x804f378 }, members of bob: c = 0 } (gdb) p dan[0].c There is no member or method named c. (gdb) n 35 dan->a=55; (gdb) p dan[0] $5 = (george2 [incomplete object]) { = { d = 0 }, = { = { a = 0, _vptr$ = 0x804f360 }, members of bob: c = 0 }, members of george2: e = 0 } (gdb) l 30 fred *dan; 31 dan=new daniel(); 32 cout <a=55; 36 cout < = { d = 0 }, = { = { a = 55, _vptr$ = 0x804f360 }, members of bob: c = 0 }, members of george2: e = 0 } (gdb) c Continuing. 7george2 Program exited normally. (gdb) q Script done on Mon Mar 13 19:34:51 2000