Re: RDI target broken in 000215 snapshot

[Grant Edwards <grante@visi.com>]

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 <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: So who maintains the web pages?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bsnyxc2iy.fsf@rtl.cygnus.com>
References: <38A60492.2BB9E437@cygnus.com> <bu2jdc2mp.fsf@rtl.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 <taylor@cygnus.com>
To: Pierre Muller <muller@cerbere.u-strasbg.fr>
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 <muller@cerbere.u-strasbg.fr>
    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 <kettenis@wins.uva.nl>
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 <blizzard@mozilla.org>

   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 <ac131313@cygnus.com>
To: Jonathan Larmour <jlarmour@redhat.co.uk>
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 <velco@fadata.bg>
To: GDB List <gdb@sourceware.cygnus.com>
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:<host>:<port>, and
udp:<host>:<port>
for TCP and UDP connections, respectively ?

Regards,
-velco
From toddpw@windriver.com Sat Apr 01 00:00:00 2000
From: Todd Whitesel <toddpw@windriver.com>
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 <ezannoni@cygnus.com> 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 <srikanth@cup.hp.com>
To: Chris Blizzard <blizzard@redhat.com>
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> <npael3tqk6.fsf@zwingli.cygnus.com> <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 <filename>
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 <msnyder@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: dan@cgsoftware.com, Mark Kettenis <kettenis@wins.uva.nl>, 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> <u2ihhvav.fsf@dan.resnet.rochester.edu> <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 <jtc@redback.com> 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;
}
    
\f
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);
}

\f
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);
    }
}

\f
/* 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++;
      }
}
\f

/* 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 <ac131313@cygnus.com>
To: Robert Lipe <robertl@sco.com>
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 <dan@cgsoftware.com>
To: gdb@sourceware.cygnus.com
Subject: RTTI working for G++
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.LNX.4.10.10003131601500.8750-100000@localhost.localdomain>
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 <<typeid(*dan).name()<<endl;
(gdb) p dan
$1 = (daniel *) 0x8051030
(gdb) p dan[0]
$2 = (daniel) {
  <fred> = {
    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) {
  <fred> = {
    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]) {
  <george> = {
    d = 0
  }, 
  <bob> = {
    <fred> = {
      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 <<typeid(*dan).name()<<endl;
33		dan=new bob();
34		dan=new george2();
35		dan->a=55;
36		cout <<typeid(*dan).name()<<endl;
37	}
38	
(gdb) n
36		cout <<typeid(*dan).name()<<endl;
(gdb) p dan
$7 = (suspicious *) 0x8050064
(gdb) p dan[0]
$8 = (george2 [incomplete object]) {
  <george> = {
    d = 0
  }, 
  <bob> = {
    <fred> = {
      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