Re: RFA: Recording MIPS ABI selection in binaries

Re: RFA: Recording MIPS ABI selection in binaries

[Nick Clifton]

Hi Chris,

: as far as i'm concerned, there could have been better use of the 
: existing bits for ABIs (by enumeration, rather than flags)

Indeed, but as you say we are stuck with legacy code which we need to
carry on supporting, so I doubt if these flags will change any time
soon.

: Personally I'd like to see the existing flags rationalized to the 
: extent that they can be, and improved from there, rather than
: perpetuate the existing morass and even make it worse by introducing a
: mechanism that's not particularly scalable,

The scheme is scalable.  In fact it is more scalable than the existing
scheme of using bits in the file header.  The sections can have
arbitrary names which can be used to encode pretty much anything.

: and is redundant with the aim of some existing mechanisms. 

Well it would be redundant if the current bits were reorganised, but I
really doubt if that is going to happen.

Cheers
	Nick
From cgd@sibyte.com Tue Aug 08 18:19:00 2000
From: cgd@sibyte.com (Chris G. Demetriou)
To: Nick Clifton <nickc@redhat.com>
Cc: gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com
Subject: Re: RFA: Recording MIPS ABI selection in binaries
Date: Tue, 08 Aug 2000 18:19:00 -0000
Message-id: <5tittb2pv3.fsf@highland.sibyte.com>
References: <200008090030.RAA19784@elmo.cygnus.com>
X-SW-Source: 2000-08/msg00165.html
Content-length: 1954

Nick Clifton <nickc@redhat.com> writes:
> : as far as i'm concerned, there could have been better use of the 
> : existing bits for ABIs (by enumeration, rather than flags)
> 
> Indeed, but as you say we are stuck with legacy code which we need to
> carry on supporting, so I doubt if these flags will change any time
> soon.

yes, i guess one of my questions was, how many of these flags are
defined by some pseudo-standard body, and how many were the invention
of the gnu tools folks.

and then, given that, how much trouble would be basically be to
declare some period of time in which nobody would set them, and
everybody would ignore them, or something, to lessen backward-compat
hassles.


Also, what's the specific case you're trying to solve?  (you said
you're talking about -mgp32... but what's the resulting ABI?  it looks
like existing bits can be used to expressed eabi32, eabi64, n32 o32,
and o64, but not "64" (but that seems to conflict with your original
statement that you need to differentiate between not using -mgp32 and
using it).



> : and is redundant with the aim of some existing mechanisms. 
> 
> Well it would be redundant if the current bits were reorganised, but I
> really doubt if that is going to happen.

certainly, nobody's going to solve the problem if every time it comes
up nobody resists new additions that go further from the 'right
thing.'  8-)


That actually makes me think:

the defined values for EF_MIPS_MACH are unused, and, really, per my
previous thought, EF_MIPS_MACH is really better expressed by something
like what you're currently proposing.  You could deprecate its use and
steal a few bits from it (looks like 4, non-contiguous), without
breaking backward compatibility with the defines in the existing
headers, if you are careful.


Also, if the goal is to have these replace the ABI flags, detection of
ABI conflicts using the new section indicators really should be added
to ld (or bfd).



cgd
From ac131313@cygnus.com Tue Aug 08 18:36:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Chris G. Demetriou" <cgd@sibyte.com>
Cc: Nick Clifton <nickc@redhat.com>, gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com
Subject: Re: RFA: Recording MIPS ABI selection in binaries
Date: Tue, 08 Aug 2000 18:36:00 -0000
Message-id: <3990B4BE.C2273617@cygnus.com>
References: <200008090030.RAA19784@elmo.cygnus.com> <5tittb2pv3.fsf@highland.sibyte.com>
X-SW-Source: 2000-08/msg00166.html
Content-length: 563

"Chris G. Demetriou" wrote:

> That actually makes me think:
> 
> the defined values for EF_MIPS_MACH are unused, and, really, per my
> previous thought, EF_MIPS_MACH is really better expressed by something
> like what you're currently proposing.  You could deprecate its use and
> steal a few bits from it (looks like 4, non-contiguous), without
> breaking backward compatibility with the defines in the existing
> headers, if you are careful.

FYI, EF_MIPS_MACH is used to determine the ISA.  Its fairly orthogonal
to ABI related flags such as -mgp32.

	Andrew
From cgd@sibyte.com Tue Aug 08 18:49:00 2000
From: cgd@sibyte.com (Chris G. Demetriou)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Nick Clifton <nickc@redhat.com>, gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com
Subject: Re: RFA: Recording MIPS ABI selection in binaries
Date: Tue, 08 Aug 2000 18:49:00 -0000
Message-id: <5thf8v2oh5.fsf@highland.sibyte.com>
References: <200008090030.RAA19784@elmo.cygnus.com> <5tittb2pv3.fsf@highland.sibyte.com> <3990B4BE.C2273617@cygnus.com>
X-SW-Source: 2000-08/msg00167.html
Content-length: 2141

Andrew Cagney <ac131313@cygnus.com> writes:
> "Chris G. Demetriou" wrote:
> > That actually makes me think:
> > 
> > the defined values for EF_MIPS_MACH are unused, and, really, per my
> > previous thought, EF_MIPS_MACH is really better expressed by something
> > like what you're currently proposing.  You could deprecate its use and
> > steal a few bits from it (looks like 4, non-contiguous), without
> > breaking backward compatibility with the defines in the existing
> > headers, if you are careful.
 
(FYI, i think i might have deleted my "previous thought" in an edit of
the message.)

> FYI, EF_MIPS_MACH is used to determine the ISA.  Its fairly orthogonal
> to ABI related flags such as -mgp32.

yes.

And what purpose is there in expressing that a binary uses exactly one
ISA's/CPU's type of instructions, i.e. why should it be encoded the
way it is?  Use of an ISA is not exclusive; you can use multiple ISAs
in a single executable, with (strongly desirable) good effect.

the type of mechanism for recording ABI Nick has proposed is not
particularly appropriate for recording ABI, since it really has no
notion of exclusivity (which as far as I can tell is appropriate for
ABI).  On the other hand, i realized that it's almost perfect for
recording ISA.  8-)

so, steal a few unused bits from that field.  old tools will think the
ISA's unknown, no biggie.  new tools faced with old binaries might get
the ABI wrong... but they'd do that anyway.

and it gets the situation closer to 'right', at least.  (believe me, i
have a strong interest in a sane solution to this problem...)


I just looked through the current set of flags in elf/mips.h.  i guess
i just don't understand why:

* any additional ABI indication needed can't be stuffed into
  one of the existing ABI enumeration slots, e.g. EF_MIPS_ABI,
  which seems to be a value rather than a set of flags, and

* all the bits seem to be gone.  (looking at the current
  header, it looks to me like 0x0f000ed8 are still available.)
  again, i don't know which are reserved by external entites,
  i.e. MTI or SGI.  But it seems that there's still some wiggle-room.



cgd
From rth@cygnus.com Tue Aug 08 19:07:00 2000
From: Richard Henderson <rth@cygnus.com>
To: "Chris G. Demetriou" <cgd@sibyte.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, Nick Clifton <nickc@redhat.com>, gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com
Subject: Re: RFA: Recording MIPS ABI selection in binaries
Date: Tue, 08 Aug 2000 19:07:00 -0000
Message-id: <20000808190706.A27768@cygnus.com>
References: <200008090030.RAA19784@elmo.cygnus.com> <5tittb2pv3.fsf@highland.sibyte.com> <3990B4BE.C2273617@cygnus.com> <5thf8v2oh5.fsf@highland.sibyte.com>
X-SW-Source: 2000-08/msg00168.html
Content-length: 1316

On Tue, Aug 08, 2000 at 06:49:10PM -0700, Chris G. Demetriou wrote:
> And what purpose is there in expressing that a binary uses exactly one
> ISA's/CPU's type of instructions, i.e. why should it be encoded the
> way it is?  Use of an ISA is not exclusive; you can use multiple ISAs
> in a single executable, with (strongly desirable) good effect.

Actually, this brings up a good point: perhaps this ought to be
done per compilation unit rather than for the entire binary.

Looking at the dwarf2 spec (and who cares about others), a likely
candidate is DW_AT_producer.  Then looking at dwarf2out.c, I see

  /* The MIPS/SGI compilers place the 'cc' command line options in the producer
     string.  The SGI debugger looks for -g, -g1, -g2, or -g3; if they do
     not appear in the producer string, the debugger reaches the conclusion
     that the object file is stripped and has no debugging information.
     To get the MIPS/SGI debugger to believe that there is debugging
     information in the object file, we add a -g to the producer string.  */
  if (debug_info_level > DINFO_LEVEL_TERSE)
    strcat (producer, " -g");

So there's precedent for looking into this string to figure out
how the binary may be interpreted.  All we'd need, then, is some
way to dump the relevant options into this string.



r~
From aoliva@redhat.com Tue Aug 08 22:31:00 2000
From: Alexandre Oliva <aoliva@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: AM33 simulator clean-up
Date: Tue, 08 Aug 2000 22:31:00 -0000
Message-id: <orsnsfq9uc.fsf@guarana.lsd.ic.unicamp.br>
X-SW-Source: 2000-08/msg00169.html
Content-length: 120

Graham Stott had posted this to a Red Hat-internal mailing list, but
it never made it to the CVS tree.  Ok to install?

Re: RFA: Recording MIPS ABI selection in binaries

[Jeffrey A Law]

  In message < 200008090030.RAA19784@elmo.cygnus.com >you write:
  > Hi Chris,
  > 
  > : as far as i'm concerned, there could have been better use of the 
  > : existing bits for ABIs (by enumeration, rather than flags)
  > 
  > Indeed, but as you say we are stuck with legacy code which we need to
  > carry on supporting, so I doubt if these flags will change any time
  > soon.
Correct.  For a number of platforms (such as many embedded MIPS chips) the
GNU tools defined the de-facto ABI.

  > : Personally I'd like to see the existing flags rationalized to the 
  > : extent that they can be, and improved from there, rather than
  > : perpetuate the existing morass and even make it worse by introducing a
  > : mechanism that's not particularly scalable,
  > 
  > The scheme is scalable.  In fact it is more scalable than the existing
  > scheme of using bits in the file header.  The sections can have
  > arbitrary names which can be used to encode pretty much anything.
Yup.  Or we can put arbitrary contents into a non-loadable section to
record information we care about.


jeff

Re: RFA: Recording MIPS ABI selection in binaries

[Michael Eager]

One of the action items I have on my plate for the Dwarf2 
committee is to write/revise a proposal for handling multiple
architectures within a single compilation/executable.  My
current thinking is that this would be handled by an extension
to the line number information.  This would permit fine 
grained specification of the ISA.  (One motivation for this
is for a processor which can switch between ISA's in the
middle of an assembly file.)

I may not have followed this thread as well as I might have.
Is the question w/r/t MIPS about identifying MIPS 3 vs MIPS 4
ISAs, or distinguishing between 32-bit and 16-bit ISAs.  The
latter is (unfortunately) encoded in the low order bit of the
target address of a jump, and cannot easily be determined by 
looking at the object file.  

This probably doesn't have any relevance to other debugging
formats.  


Richard Henderson wrote:
> 
> On Wed, Aug 09, 2000 at 10:10:50AM -0700, Chris G. Demetriou wrote:
> > * should it even be compilation unit granularity?  It seems that a
> > mechanism for finer granularity would be appropriate...
> 
> Well, as proposed it would be in the CIE record, which is nominally
> one compilation unit.  You could have more than one per unit if you
> wished.
> 
> > it's possible to use different ISA assembly at finer granularity than
> > that, if you're coding in assembly.
> 
> If you're coding in assembly, you may be hard-pressed to get this
> information into the object file.  It's not easy to write dwarf2
> by hand; the assembler can do some (line numbers and such) but there's
> no existing mechanism by which to get stuff into the producer string.
> 
> > * is it actually easy for objdump to make use of debugging
> > information?
> 
> Not exactly.
> 
> r~


-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
From rth@cygnus.com Wed Aug 09 11:09:00 2000
From: Richard Henderson <rth@cygnus.com>
To: Michael Eager <eager@eagercon.com>
Cc: "Chris G. Demetriou" <cgd@sibyte.com>, Andrew Cagney <ac131313@cygnus.com>, Nick Clifton <nickc@redhat.com>, gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com
Subject: Re: RFA: Recording MIPS ABI selection in binaries
Date: Wed, 09 Aug 2000 11:09:00 -0000
Message-id: <20000809110906.B28831@cygnus.com>
References: <200008090030.RAA19784@elmo.cygnus.com> <5tittb2pv3.fsf@highland.sibyte.com> <3990B4BE.C2273617@cygnus.com> <5thf8v2oh5.fsf@highland.sibyte.com> <20000808190706.A27768@cygnus.com> <39918757.8F2BD597@cygnus.com> <5tg0oez7fp.fsf@highland.sibyte.com> <20000809104623.D28802@cygnus.com> <39919C53.91818790@eagercon.com>
X-SW-Source: 2000-08/msg00178.html
Content-length: 383

On Wed, Aug 09, 2000 at 11:00:51AM -0700, Michael Eager wrote:
> I may not have followed this thread as well as I might have.
> Is the question w/r/t MIPS about identifying MIPS 3 vs MIPS 4
> ISAs, or distinguishing between 32-bit and 16-bit ISAs.

Actually the thread started not with ISAs but ABIs.  In
particular, letting the debugger recognize a 32-bit ABI
on a 64-bit ISA.


r~
From cgd@sibyte.com Wed Aug 09 11:13:00 2000
From: cgd@sibyte.com (Chris G. Demetriou)
To: law@cygnus.com
Cc: nickc@redhat.com (Nick Clifton), gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com
Subject: Re: RFA: Recording MIPS ABI selection in binaries
Date: Wed, 09 Aug 2000 11:13:00 -0000
Message-id: <5tbsz2z4kq.fsf@highland.sibyte.com>
References: <23389.965836696@upchuck>
X-SW-Source: 2000-08/msg00179.html
Content-length: 1601

Jeffrey A Law <law@cygnus.com> writes:
> As to the new architectures -- feel free to send a patch to support them.

So, the more expanded reply to this:

We (SiByte) have substantial patches which we would like to contribute
back to the community relating to MIPS32 and MIPS64 support in gcc,
gdb, and the binutils, including modifications to the GDB simulator
which enable it to pass the MIPS32 and MIPS64 AVPs.  However, the
changes were made using documentation which is currently still under
non-disclosure with MIPS Technologies (but which supposedly will be
made available for general release eventually).

We have been given permission by MTI to send patches to Cygnus for the
sole purpose of helping Cygnus complete its work on the MIPS simulator
for MTI.  We may be able to get a release for additional changes
(e.g., the the compiler or binutils), but in all likelyhood, until
we're released from the NDA, we'd still only be able to send bits to
Cygnus directly (i.e., not the lists).

If there are Cygnus employees who would like to receive these changes
and investigate them for the purpose of enhancing some of the work
done for MTI, we'd be quite glad to investigate that further (and, if
appropriate, would be willing to go to the effort of asking MTI for
the ability to release our other changes to Cygnus, as well).


(Obviously, I mean "Cygnus, a division of Red Hat, Inc.," or whatever
terminologu is appropriate today, when I say "Cygnus."  I still think
of it as the latter, but I know that that's no longer correct, and he
former is how our release from MTI is phrased.)


chris
From fnasser@cygnus.com Wed Aug 09 11:26:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Jim Ingham <jingham@apple.com>
Cc: Jimmy Guo <guo@cup.hp.com>, Andrew Cagney <ac131313@cygnus.com>, Geoff Keating <geoffk@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: recent dejagnu changes
Date: Wed, 09 Aug 2000 11:26:00 -0000
Message-id: <3991A228.F5005FAB@cygnus.com>
References: <B5B6E9E2.3E02%jingham@apple.com>
X-SW-Source: 2000-08/msg00180.html
Content-length: 2257

Jim Ingham wrote:
> 
> Before this thread is entirely retired, it is a little worthwhile to point
> out that it is REALLY unfortunate that the testing framework for a set of
> tools as important as gdb & gcc has NO maintainer (and is in such generally
> poor shape as Dejagnu undoubtly is).  Now, I am not myself volunteering - I
> have a spare time Free Software project already and no spare time to boot.
> And I realize that some similar thing is probably true of everyone on this
> list.  However, I also bet that many of the people on this list have started
> out to make some simple change to dejagnu, and ended up wasting hours
> tearing their hair out over this or that infelicity in the Dejagnu source...
> 

Although there is no official maintainer for Dejagnu specifically, Stan and I have
been trying to do a "keep it alive" sort of maintainership as part of the 
gdb testsuite maintainership.  That is why we do the patches reviews and approvals.

This means that we have revised the patches with help from people like Jim Bandy,
Elena Zannoni and many others that have used their spare cycles in helping this.

The situation of dejagnu is like other shared code like the disassembly.
That one, also used by gdb, is maintained by binutils people.  Dejagnu, although
also used by gcc, has been under gdb umbrella because we are the group that has
to deal with Tcl.

What Jim is probably refering to is people who actually spend time improving, 
cleaning up, etc.  This seems to require, more than never, some sort of sponsorship
(time == money) at least to get it out of the ground.  But it is hard to get investiments
for test software.  And, for some reason, it seems to be hard to get Tcl based projects
sponsored as well.  The current state is a consequence...

> This is a very unsatisfactory situation, and we need to do something about
> it.  I have no solution, just thought it is worthwhile to point out that the
> problem is more serious than just a mild collision between a couple of users
> of Dejagnu..
> 

I agree.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From davea@quasar.engr.sgi.com Wed Aug 09 11:51:00 2000
From: David B Anderson <davea@quasar.engr.sgi.com>
To: cgd@sibyte.com
Cc: gdb-patches@sources.redhat.com, gcc-patches@gcc.gnu.org, nickc@redhat.com
Subject: Re: RFA: Recording MIPS ABI selection in binaries
Date: Wed, 09 Aug 2000 11:51:00 -0000
Message-id: <200008091850.LAA60350@quasar.engr.sgi.com>
X-SW-Source: 2000-08/msg00181.html
Content-length: 2954

Relating to e_flags and MIPS/SGI on gdb-patches:

It's not clear to me *which* bits folks think are unused, but
The following is the latest   e_flags info from SGI headers
in the compiler tree (MIPSpro7.3.1.2m, unreleased at this time).

Some flags here appear not to be mentioned in elf/mips.h in gdb,
so I though you all might want to know this!

I don't recall we actually generate ASE (see below)
stuff in the SGI compilers (I didn't check with the
code generator folks, though I could if that seems
appropriate).


/* ====================================================================
 *
 * Elf header
 *
 * ====================================================================
 */

/*
 * e_flags
 */

#define EF_MIPS_NOREORDER       0x00000001
#define EF_MIPS_OPSEX           EF_MIPS_NOREORDER
#define EF_MIPS_PIC             0x00000002
#define EF_MIPS_CPIC            0x00000004
#define EF_MIPS_XGOT            0x00000008
#define EF_MIPS_OPTIONS_FIRST   0x00000080 
/* obsolete names */
#define EF_MIPS_UGEN_ALLOC      EF_MIPS_XGOT
#define EF_MIPS_UGEN_RESERVED   EF_MIPS_64BIT_WHIRL

#define EF_MIPS_ABI64           EF_IRIX_ABI64
        /* see explanation in /usr/include/sys/elf.h    */

#define EF_MIPS_64BIT_WHIRL     EF_MIPS_ABI64
        /* This is here for compatibility with pre-v7.4 compiler objects. */

#define EF_MIPS_ABI2            0x00000020 
        /* indicates n32 as opposed to o32 */

/*
 *      The EF_MIPS_ARCH field of e_flags describes the ISA of the object.
 *              size:   4 bits
 *              type:   int
 */
#define EF_MIPS_ARCH            0xf0000000      /* mask: 4 bit field */
#define EF_MIPS_ARCH_1          0x00000000
#define EF_MIPS_ARCH_2          0x10000000
#define EF_MIPS_ARCH_3          0x20000000
#define EF_MIPS_ARCH_4          0x30000000
#define EF_MIPS_ARCH_5          0x40000000
#define EF_MIPS_ARCH_6          0x50000000

/*
 *      The EF_MIPS_ARCH_ASE field of e_flags describes the set of 
 *      Application Specific Extensions used by the object.
 *              size:   4 bits
 *              type:   bit-field
 */
#define EF_MIPS_ARCH_ASE        0x0f000000      /* mask: 4 bit field    */
#define EF_MIPS_ARCH_ASE_MDMX   0x08000000      /* multi-media extensions*/
#define EF_MIPS_ARCH_ASE_M16    0x04000000      /* MIPS16 isa extensions */

/*
 *      Please reserve these 8 bits of e_flags for future
 *      expansion of the EF_MIPS_ARCH_ASE field;  increasing
 *      the field from 4 bits to 12 bits.
 *      
 *              0x00ff0000      
 *      
 *      If and when we expand it, we'll redefine the EF_MIPS_ARCH_ASE 
 *      macro to be:
 *      
 *              0x0fff0000.
 */


And sys/elf.h defines, for e_flags:
elf.h:#define        EF_IRIX_ABI64           0x00000010

If there are questions on SGI usage (of anything)
that I might be able to help with don't hesitate to ask.

Regards,
David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/
From jtc@redback.com Wed Aug 09 12:01:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: dcache corruption bug
Date: Wed, 09 Aug 2000 12:01:00 -0000
Message-id: <5mya26p8dt.fsf@jtc.redback.com>
X-SW-Source: 2000-08/msg00182.html
Content-length: 4912

While adopting dcache for memory region attributes, I discovered what
appears to be a potential cache corruption, plus a nit that the 'refs'
field is never zeroed when a cache line is re-cycled, which makes it 
somewhat less than useful.

The comment for dcache_alloc() states its caller should remove the
returned dcache_block from the free list and place it on the valid
list to prevent cache corruption.  Good idea, but the code actually
removes a dcache_block from the free list (or recycles one from the
valid list) and inserts it on the valid list.  Because none of the 
fields are re-initialized, if the caller does not do it the contents
of the cache block could be written to memory.

This was the case for dcache_peek_byte().  If a new block was
allocated, and for some reason the read failed, the block would have
the contents of the previous cache line that used the block.

I don't think that bad values would be ever be written; the line would
have been flushed before the block was re-cycled. But bytes with state
ENTRY_OK would return the old values in subsequent reads.

To fix this problem, I changed dcache_alloc() to initialize the
address and invalidate the cache line before returning a new block.

Other related issues:

* dcache makes no attempt to remove the least-recently-used block when
  a cache line is recycled.  When a new cache-line is allocated it is
  added to the tail of the valid list.  If there aren't any cache-lines
  in the free list, the one from the head of the valid list is recycled.
  Anyone have any reasons why making this a LRU cache is a bad idea?

* dcache has a free list and a valid list.  Why not just have one list 
  and invalidate unused cache lines.  When we need a new block, we can
  just grab a line from the pool.  With a LRU cache, the unused blocks
  will be the ones subject for re-cycling.

* Is there a generic set of list manipulation macros in libiberty?  I
  thought there was, but couldn't find anything.


        --jtc

2000-08-09  J.T. Conklin  <jtc@redback.com>

        * dcache.c (dcache_alloc): Changed to take address of line as an
        argument, and to invalidate cache line before returning.
        (dcache_peek_byte): Updated.
        (dcache_poke_byte): Updated.


Index: dcache.c
===================================================================
RCS file: /cvs/src/src/gdb/dcache.c,v
retrieving revision 1.5
diff -c -r1.5 dcache.c
*** dcache.c	2000/07/30 01:48:25	1.5
--- dcache.c	2000/08/09 18:17:28
***************
*** 157,163 ****
  
  static int dcache_write_line (DCACHE * dcache, struct dcache_block *db);
  
! static struct dcache_block *dcache_alloc (DCACHE * dcache);
  
  static int dcache_writeback (DCACHE * dcache);
  
--- 157,163 ----
  
  static int dcache_write_line (DCACHE * dcache, struct dcache_block *db);
  
! static struct dcache_block *dcache_alloc (DCACHE * dcache, CORE_ADDR addr);
  
  static int dcache_writeback (DCACHE * dcache);
  
***************
*** 267,281 ****
  
  
  /* Get a free cache block, put or keep it on the valid list,
!    and return its address.  The caller should store into the block
!    the address and data that it describes, then remque it from the
!    free list and insert it into the valid list.  This procedure
!    prevents errors from creeping in if a memory retrieval is
!    interrupted (which used to put garbage blocks in the valid
!    list...).  */
  
  static struct dcache_block *
! dcache_alloc (DCACHE *dcache)
  {
    register struct dcache_block *db;
  
--- 267,276 ----
  
  
  /* Get a free cache block, put or keep it on the valid list,
!    and return its address.  */
  
  static struct dcache_block *
! dcache_alloc (DCACHE *dcache, CORE_ADDR addr)
  {
    register struct dcache_block *db;
  
***************
*** 297,302 ****
--- 292,302 ----
        dcache_write_line (dcache, db);
      }
  
+   db->addr = MASK(addr);
+   db->refs = 0;
+   db->anydirty = 0;
+   memset (db->state, ENTRY_BAD, sizeof (db->data));
+ 
    /* append this line to end of valid list */
    if (!dcache->valid_head)
      dcache->valid_head = db;
***************
*** 327,335 ****
  	  dcache_write_line (dcache, db);
  	}
        else
! 	db = dcache_alloc (dcache);
        immediate_quit++;
-       db->addr = MASK (addr);
        while (done < LINE_SIZE)
  	{
  	  int try =
--- 327,335 ----
  	  dcache_write_line (dcache, db);
  	}
        else
! 	db = dcache_alloc (dcache, addr);
! 
        immediate_quit++;
        while (done < LINE_SIZE)
  	{
  	  int try =
***************
*** 379,387 ****
  
    if (!db)
      {
!       db = dcache_alloc (dcache);
!       db->addr = MASK (addr);
!       memset (db->state, ENTRY_BAD, sizeof (db->data));
      }
  
    db->data[XFORM (addr)] = *ptr;
--- 379,385 ----
  
    if (!db)
      {
!       db = dcache_alloc (dcache, addr);
      }
  
    db->data[XFORM (addr)] = *ptr;



-- 
J.T. Conklin
RedBack Networks
From shebs@apple.com Wed Aug 09 12:25:00 2000
From: Stan Shebs <shebs@apple.com>
To: Jim Ingham <jingham@apple.com>
Cc: Jimmy Guo <guo@cup.hp.com>, Andrew Cagney <ac131313@cygnus.com>, Geoff Keating <geoffk@cygnus.com>, fnasser@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: recent dejagnu changes
Date: Wed, 09 Aug 2000 12:25:00 -0000
Message-id: <3991AE06.6FB9D435@apple.com>
References: <B5B6E9E2.3E02%jingham@apple.com>
X-SW-Source: 2000-08/msg00183.html
Content-length: 1090

Jim Ingham wrote:
> 
> [...] it is a little worthwhile to point
> out that it is REALLY unfortunate that the testing framework for a set of
> tools as important as gdb & gcc has NO maintainer (and is in such generally
> poor shape as Dejagnu undoubtly is).

I agree completely.  Last year Rob Savoye was claiming to be working on
a new and improved DejaGNU, but there's no evidence of progress; in fact,
his site seems to be incommunicado.  He had also created a Sourceforge
project, but the only information on it says:

   I'm sorry, this project is removed while I work out some nasty release
   problems, none of which are technical ones... I have hopes these can be
   solved, and active development is continuing.

My sense of responsibility urges me to take up the banner before things fall
apart, but in my current situation that's not very realistic.  Cygnus
engineers are the best candidates since they have access to the greatest
variety of hosts and targets, but somebody would have to be motivated
enough to make the case to mgmt that they should get the dedicated time.

Stan
From msnyder@cygnus.com Wed Aug 09 13:08:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH]: MULTI_ARCH fix-up
Date: Wed, 09 Aug 2000 13:08:00 -0000
Message-id: <200008092008.NAA11112@cleaver.cygnus.com>
X-SW-Source: 2000-08/msg00184.html
Content-length: 9376

2000-08-09  Michael Snyder  <msnyder@cleaver.cygnus.com>

        * blockframe.c (sigtramp_saved_pc): Use dynamic allocation,
        since TARGET_PTR_BIT is no longer a constant (MULTI_ARCH).
        * irix4-nat.c (get_longjmp_target): Ditto.
        * irix5-nat.c (get_longjmp_target): Ditto.
        * jv-valprint.c (java_value_print): Ditto.
        * m3-nat.c (get_cprocs):            Ditto.
        * m68k-tdep.c (get_longjmp_target): Ditto.
        * mips-nat.c  (get_longjmp_target): Ditto.
        * mipsv4-nat.c(get_longjmp_target): Ditto.
        * pa64solib.c (read_dynamic_info):  Ditto.
        * solib.c (elf_locate_base):        Ditto.

Index: blockframe.c
===================================================================
RCS file: /cvs/src/src/gdb/blockframe.c,v
retrieving revision 1.5
diff -p -r1.5 blockframe.c
*** blockframe.c	2000/07/30 01:48:24	1.5
--- blockframe.c	2000/08/09 20:07:01
*************** CORE_ADDR
*** 950,959 ****
  sigtramp_saved_pc (struct frame_info *frame)
  {
    CORE_ADDR sigcontext_addr;
!   char buf[TARGET_PTR_BIT / TARGET_CHAR_BIT];
    int ptrbytes = TARGET_PTR_BIT / TARGET_CHAR_BIT;
    int sigcontext_offs = (2 * TARGET_INT_BIT) / TARGET_CHAR_BIT;
  
    /* Get sigcontext address, it is the third parameter on the stack.  */
    if (frame->next)
      sigcontext_addr = read_memory_integer (FRAME_ARGS_ADDRESS (frame->next)
--- 950,960 ----
  sigtramp_saved_pc (struct frame_info *frame)
  {
    CORE_ADDR sigcontext_addr;
!   char *buf;
    int ptrbytes = TARGET_PTR_BIT / TARGET_CHAR_BIT;
    int sigcontext_offs = (2 * TARGET_INT_BIT) / TARGET_CHAR_BIT;
  
+   buf = alloca (ptrbytes);
    /* Get sigcontext address, it is the third parameter on the stack.  */
    if (frame->next)
      sigcontext_addr = read_memory_integer (FRAME_ARGS_ADDRESS (frame->next)
Index: irix4-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/irix4-nat.c,v
retrieving revision 1.4
diff -p -r1.4 irix4-nat.c
*** irix4-nat.c	2000/07/30 01:48:25	1.4
--- irix4-nat.c	2000/08/09 20:07:01
*************** fill_fpregset (fpregset_t *fpregsetp, in
*** 145,153 ****
  int
  get_longjmp_target (CORE_ADDR *pc)
  {
!   char buf[TARGET_PTR_BIT / TARGET_CHAR_BIT];
    CORE_ADDR jb_addr;
  
    jb_addr = read_register (A0_REGNUM);
  
    if (target_read_memory (jb_addr + JB_PC * JB_ELEMENT_SIZE, buf,
--- 145,154 ----
  int
  get_longjmp_target (CORE_ADDR *pc)
  {
!   char *buf;
    CORE_ADDR jb_addr;
  
+   buf = alloca (TARGET_PTR_BIT / TARGET_CHAR_BIT);
    jb_addr = read_register (A0_REGNUM);
  
    if (target_read_memory (jb_addr + JB_PC * JB_ELEMENT_SIZE, buf,
Index: irix5-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/irix5-nat.c,v
retrieving revision 1.7
diff -p -r1.7 irix5-nat.c
*** irix5-nat.c	2000/07/30 01:48:25	1.7
--- irix5-nat.c	2000/08/09 20:07:01
*************** fill_fpregset (fpregset_t *fpregsetp, in
*** 165,173 ****
  int
  get_longjmp_target (CORE_ADDR *pc)
  {
!   char buf[TARGET_PTR_BIT / TARGET_CHAR_BIT];
    CORE_ADDR jb_addr;
  
    jb_addr = read_register (A0_REGNUM);
  
    if (target_read_memory (jb_addr + JB_PC * JB_ELEMENT_SIZE, buf,
--- 165,174 ----
  int
  get_longjmp_target (CORE_ADDR *pc)
  {
!   char *buf;
    CORE_ADDR jb_addr;
  
+   buf = alloca (TARGET_PTR_BIT / TARGET_CHAR_BIT);
    jb_addr = read_register (A0_REGNUM);
  
    if (target_read_memory (jb_addr + JB_PC * JB_ELEMENT_SIZE, buf,
Index: jv-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/jv-valprint.c,v
retrieving revision 1.3
diff -p -r1.3 jv-valprint.c
*** jv-valprint.c	2000/07/30 01:48:26	1.3
--- jv-valprint.c	2000/08/09 20:07:01
*************** java_value_print (value_ptr val, struct 
*** 96,103 ****
  
  	  while (i < length && things_printed < print_max)
  	    {
! 	      char buf[TARGET_PTR_BIT / HOST_CHAR_BIT];
  
  	      fputs_filtered (", ", stream);
  	      wrap_here (n_spaces (2));
  
--- 96,104 ----
  
  	  while (i < length && things_printed < print_max)
  	    {
! 	      char *buf;
  
+ 	      buf = alloca (TARGET_PTR_BIT / HOST_CHAR_BIT);
  	      fputs_filtered (", ", stream);
  	      wrap_here (n_spaces (2));
  
Index: m3-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/m3-nat.c,v
retrieving revision 1.3
diff -p -r1.3 m3-nat.c
*** m3-nat.c	2000/07/30 01:48:26	1.3
--- m3-nat.c	2000/08/09 20:07:01
*************** get_cprocs (void)
*** 2460,2470 ****
    gdb_thread_t cproc_head;
    gdb_thread_t cproc_copy;
    CORE_ADDR their_cprocs;
!   char *buf[TARGET_PTR_BIT / HOST_CHAR_BIT];
    char *name;
    cthread_t cthread;
    CORE_ADDR symaddr;
  
    symaddr = lookup_address_of_variable ("cproc_list");
  
    if (!symaddr)
--- 2460,2471 ----
    gdb_thread_t cproc_head;
    gdb_thread_t cproc_copy;
    CORE_ADDR their_cprocs;
!   char *buf;
    char *name;
    cthread_t cthread;
    CORE_ADDR symaddr;
  
+   buf = alloca (TARGET_PTR_BIT / HOST_CHAR_BIT);
    symaddr = lookup_address_of_variable ("cproc_list");
  
    if (!symaddr)
Index: m68k-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/m68k-tdep.c,v
retrieving revision 1.6
diff -p -r1.6 m68k-tdep.c
*** m68k-tdep.c	2000/07/30 01:48:26	1.6
--- m68k-tdep.c	2000/08/09 20:07:01
*************** fill_fpregset (fpregset_t *fpregsetp, in
*** 646,654 ****
  int
  get_longjmp_target (CORE_ADDR *pc)
  {
!   char buf[TARGET_PTR_BIT / TARGET_CHAR_BIT];
    CORE_ADDR sp, jb_addr;
  
    sp = read_register (SP_REGNUM);
  
    if (target_read_memory (sp + SP_ARG0,		/* Offset of first arg on stack */
--- 646,655 ----
  int
  get_longjmp_target (CORE_ADDR *pc)
  {
!   char *buf;
    CORE_ADDR sp, jb_addr;
  
+   buf = alloca (TARGET_PTR_BIT / TARGET_CHAR_BIT);
    sp = read_register (SP_REGNUM);
  
    if (target_read_memory (sp + SP_ARG0,		/* Offset of first arg on stack */
Index: mips-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/mips-nat.c,v
retrieving revision 1.3
diff -p -r1.3 mips-nat.c
*** mips-nat.c	2000/07/30 01:48:26	1.3
--- mips-nat.c	2000/08/09 20:07:01
*************** int
*** 137,144 ****
  get_longjmp_target (CORE_ADDR *pc)
  {
    CORE_ADDR jb_addr;
!   char buf[TARGET_PTR_BIT / TARGET_CHAR_BIT];
  
    jb_addr = read_register (A0_REGNUM);
  
    if (target_read_memory (jb_addr + JB_PC * JB_ELEMENT_SIZE, buf,
--- 137,145 ----
  get_longjmp_target (CORE_ADDR *pc)
  {
    CORE_ADDR jb_addr;
!   char *buf;
  
+   buf = alloca (TARGET_PTR_BIT / TARGET_CHAR_BIT);
    jb_addr = read_register (A0_REGNUM);
  
    if (target_read_memory (jb_addr + JB_PC * JB_ELEMENT_SIZE, buf,
Index: mipsv4-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/mipsv4-nat.c,v
retrieving revision 1.3
diff -p -r1.3 mipsv4-nat.c
*** mipsv4-nat.c	2000/07/30 01:48:26	1.3
--- mipsv4-nat.c	2000/08/09 20:07:01
*************** fill_fpregset (fpregset_t *fpregsetp, in
*** 143,151 ****
  int
  get_longjmp_target (CORE_ADDR *pc)
  {
!   char buf[TARGET_PTR_BIT / TARGET_CHAR_BIT];
    CORE_ADDR jb_addr;
  
    jb_addr = read_register (A0_REGNUM);
  
    if (target_read_memory (jb_addr + _JB_PC * JB_ELEMENT_SIZE, buf,
--- 143,152 ----
  int
  get_longjmp_target (CORE_ADDR *pc)
  {
!   char *buf;
    CORE_ADDR jb_addr;
  
+   buf = alloca (TARGET_PTR_BIT / TARGET_CHAR_BIT);
    jb_addr = read_register (A0_REGNUM);
  
    if (target_read_memory (jb_addr + _JB_PC * JB_ELEMENT_SIZE, buf,
Index: pa64solib.c
===================================================================
RCS file: /cvs/src/src/gdb/pa64solib.c,v
retrieving revision 1.5
diff -p -r1.5 pa64solib.c
*** pa64solib.c	2000/07/30 01:48:26	1.5
--- pa64solib.c	2000/08/09 20:07:01
*************** read_dynamic_info (asection *dyninfo_sec
*** 1019,1026 ****
        Elf64_Dyn *x_dynp = (Elf64_Dyn*)buf;
        Elf64_Sxword dyn_tag;
        CORE_ADDR	dyn_ptr;
!       char pbuf[TARGET_PTR_BIT / HOST_CHAR_BIT];
  
        dyn_tag = bfd_h_get_64 (symfile_objfile->obfd, 
  			      (bfd_byte*) &x_dynp->d_tag);
  
--- 1019,1027 ----
        Elf64_Dyn *x_dynp = (Elf64_Dyn*)buf;
        Elf64_Sxword dyn_tag;
        CORE_ADDR	dyn_ptr;
!       char *pbuf;
  
+       pbuf = alloca (TARGET_PTR_BIT / HOST_CHAR_BIT);
        dyn_tag = bfd_h_get_64 (symfile_objfile->obfd, 
  			      (bfd_byte*) &x_dynp->d_tag);
  
Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.19
diff -p -r1.19 solib.c
*** solib.c	2000/08/07 10:56:22	1.19
--- solib.c	2000/08/09 20:07:01
*************** elf_locate_base (void)
*** 762,769 ****
  #ifdef DT_MIPS_RLD_MAP
  	  else if (dyn_tag == DT_MIPS_RLD_MAP)
  	    {
! 	      char pbuf[TARGET_PTR_BIT / HOST_CHAR_BIT];
  
  	      /* DT_MIPS_RLD_MAP contains a pointer to the address
  		 of the dynamic link structure.  */
  	      dyn_ptr = bfd_h_get_32 (exec_bfd, 
--- 762,770 ----
  #ifdef DT_MIPS_RLD_MAP
  	  else if (dyn_tag == DT_MIPS_RLD_MAP)
  	    {
! 	      char *pbuf;
  
+ 	      pbuf = alloca (TARGET_PTR_BIT / HOST_CHAR_BIT);
  	      /* DT_MIPS_RLD_MAP contains a pointer to the address
  		 of the dynamic link structure.  */
  	      dyn_ptr = bfd_h_get_32 (exec_bfd, 
From tprince@computer.org Wed Aug 09 13:33:00 2000
From: "Tim Prince" <tprince@computer.org>
To: "DJ Delorie" <dj@delorie.com>
Cc: <binutils@sources.redhat.com>, <gdb-patches@sources.redhat.com>
Subject: patch to correct linker mis-alignments for cygwin 1.1.3 
Date: Wed, 09 Aug 2000 13:33:00 -0000
Message-id: <006401c00241$36cf77f0$0100000a@TIMYX18EWDT6RQ>
References: <000701c00154$7bfcce60$0100000a@TIMYX18EWDT6RQ> <200008081629.MAA26945@envy.delorie.com> <002301c001c6$e95889a0$0100000a@TIMYX18EWDT6RQ> <200008091736.NAA15337@envy.delorie.com>
X-SW-Source: 2000-08/msg00185.html
Content-type: multipart/mixed; boundary="----------=_1583534356-29877-17"

This is a multi-part message in MIME format...

------------=_1583534356-29877-17
Content-length: 910

This patch (suggested by DJ Delorie) corrects the mis-alignment induced
performance problem with double [precision] storage under cygwin, also
improving, but not fully correcting, the lapses in application of
.p2align.

Although it requests 128-bit alignment, it produces 64-bit alignment in
cygwin, still a valuable improvement over the previous 32-bit alignment.

Make check results not affected by this patch.
Tested with stock gcc-2.95.2 binary under cygwin, and by bootstrapping
gcc-2.96 snapshot under cygwin.

Patch .diff and suggested ChangeLog entries attached

I have assignment forms accepted by FSF.

Tim Prince
----- Original Message -----
From: "DJ Delorie" <dj@delorie.com>
To: <tprince@computer.org>
Cc: <cygwin@sourceware.cygnus.com>
Sent: Wednesday, August 09, 2000 10:36 AM
Subject: Re: linker mis-alignments for cygwin 1.1.3


>
> Feel free to submit a patch to binutils@sources.redhat.com

------------=_1583534356-29877-17
Content-Type: text/x-diff; charset=us-ascii; name="cygcoffpatch.diff"
Content-Disposition: inline; filename="cygcoffpatch.diff"
Content-Transfer-Encoding: base64
Content-Length: 659

KioqIGJmZC9jb2ZmLWkzODYuYwlUdWUgQXVnICA4IDE5OjU4OjI4IDIwMDAK
LS0tIGJmZC9jb2ZmLWkzODYuY34JU2F0IEp1biAyNCAxODo1MjoxNCAyMDAw
CioqKioqKioqKioqKioqKiBzdGF0aWMgcmVsb2NfaG93dG9fdHlwZSAqY29m
Zl9pMzg2X3JlbG9jCioqKiA0Nyw1MSAqKioqCiAgICBQQVJBTVMgKChiZmQg
KiwgYmZkX3JlbG9jX2NvZGVfcmVhbF90eXBlKSk7CiAgCiEgI2RlZmluZSBD
T0ZGX0RFRkFVTFRfU0VDVElPTl9BTElHTk1FTlRfUE9XRVIgKDQpCiAgLyog
VGhlIHBhZ2Ugc2l6ZSBpcyBhIGd1ZXNzIGJhc2VkIG9uIEVMRi4gICovCiAg
Ci0tLSA0Nyw1MSAtLS0tCiAgICBQQVJBTVMgKChiZmQgKiwgYmZkX3JlbG9j
X2NvZGVfcmVhbF90eXBlKSk7CiAgCiEgI2RlZmluZSBDT0ZGX0RFRkFVTFRf
U0VDVElPTl9BTElHTk1FTlRfUE9XRVIgKDIpCiAgLyogVGhlIHBhZ2Ugc2l6
ZSBpcyBhIGd1ZXNzIGJhc2VkIG9uIEVMRi4gICovCiAgCg==

------------=_1583534356-29877-17--
From jtc@redback.com Wed Aug 09 16:17:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: patch to invalidate dcache in .to_open vector
Date: Wed, 09 Aug 2000 16:17:00 -0000
Message-id: <5m66paowj1.fsf@jtc.redback.com>
X-SW-Source: 2000-08/msg00186.html
Content-length: 6306

I submit the enclosed patch for approval.

I found that most of .to_open vectors which call dcache_init() do so
even if the dcache has been created in an earlier call.  This leads to
a dcache-sized memory leak each time the target is opened.  Instead,
the cache should be invalidated ("flushed" using gdb's strange sense
of the word --- I swear I'm going to change that soon :-).

        --jtc

2000-08-09  J.T. Conklin  <jtc@redback.com>

	* monitor.c (monitor_open): If a dcache has already been created,
	invalidate it rather than creating another.
	* ocd.c (ocd_open): Likewise.
	* remote-nindy.c (nindy_open): Likewise.
	* remote-sds.c (sds_open): Likewise.
	* remote-utils.c (gr_open): Likewise.
	* remote.c (remote_open_1, remote_cisco_open): Likewise.

Index: monitor.c
===================================================================
RCS file: /cvs/src/src/gdb/monitor.c,v
retrieving revision 1.8
diff -c -r1.8 monitor.c
*** monitor.c	2000/07/30 01:48:26	1.8
--- monitor.c	2000/08/09 22:45:47
***************
*** 838,847 ****
  
    monitor_printf (current_monitor->line_term);
  
!   if (current_monitor->flags & MO_HAS_BLOCKWRITES)
!     remote_dcache = dcache_init (monitor_read_memory, monitor_write_memory_block);
    else
!     remote_dcache = dcache_init (monitor_read_memory, monitor_write_memory);
    start_remote ();
  }
  
--- 838,854 ----
  
    monitor_printf (current_monitor->line_term);
  
!   if (!remote_dcache)
!     {
!       if (current_monitor->flags & MO_HAS_BLOCKWRITES)
! 	remote_dcache = dcache_init (monitor_read_memory, 
! 				     monitor_write_memory_block);
!       else
! 	remote_dcache = dcache_init (monitor_read_memory, monitor_write_memory);
!     }
    else
!     dcache_flush (remote_dcache);
! 
    start_remote ();
  }
  
Index: ocd.c
===================================================================
RCS file: /cvs/src/src/gdb/ocd.c,v
retrieving revision 1.5
diff -c -r1.5 ocd.c
*** ocd.c	2000/07/30 01:48:26	1.5
--- ocd.c	2000/08/09 22:45:48
***************
*** 292,298 ****
  
    unpush_target (current_ops);
  
!   ocd_dcache = dcache_init (ocd_read_bytes, ocd_write_bytes);
  
    if (strncmp (name, "wiggler", 7) == 0)
      {
--- 292,301 ----
  
    unpush_target (current_ops);
  
!   if (!ocd_dcache)
!     ocd_dcache = dcache_init (ocd_read_bytes, ocd_write_bytes);
!   else
!     dcache_flush (ocd_dcache);
  
    if (strncmp (name, "wiggler", 7) == 0)
      {
Index: remote-nindy.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-nindy.c,v
retrieving revision 1.5
diff -c -r1.5 remote-nindy.c
*** remote-nindy.c	2000/07/30 01:48:26	1.5
--- remote-nindy.c	2000/08/09 22:45:48
***************
*** 187,193 ****
    nindy_close (0);
  
    have_regs = regs_changed = 0;
!   nindy_dcache = dcache_init (ninMemGet, ninMemPut);
  
    /* Allow user to interrupt the following -- we could hang if there's
       no NINDY at the other end of the remote tty.  */
--- 187,197 ----
    nindy_close (0);
  
    have_regs = regs_changed = 0;
! 
!   if (!nindy_dcache)
!     nindy_dcache = dcache_init (ninMemGet, ninMemPut);
!   else
!     dcache_flush (nindy_dcache);
  
    /* Allow user to interrupt the following -- we could hang if there's
       no NINDY at the other end of the remote tty.  */
Index: remote-sds.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-sds.c,v
retrieving revision 1.4
diff -c -r1.4 remote-sds.c
*** remote-sds.c	2000/07/30 01:48:27	1.4
--- remote-sds.c	2000/08/09 22:45:49
***************
*** 203,209 ****
  
    unpush_target (&sds_ops);
  
!   sds_dcache = dcache_init (sds_read_bytes, sds_write_bytes);
  
    sds_desc = SERIAL_OPEN (name);
    if (!sds_desc)
--- 203,212 ----
  
    unpush_target (&sds_ops);
  
!   if (!sds_dcache)
!     sds_dcache = dcache_init (sds_read_bytes, sds_write_bytes);
!   else
!     dcache_flush (sds_dcache);
  
    sds_desc = SERIAL_OPEN (name);
    if (!sds_desc)
Index: remote-utils.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-utils.c,v
retrieving revision 1.4
diff -c -r1.4 remote-utils.c
*** remote-utils.c	2000/07/30 01:48:27	1.4
--- remote-utils.c	2000/08/09 22:45:49
***************
*** 154,166 ****
  void
  gr_open (char *args, int from_tty, struct gr_settings *gr)
  {
    target_preopen (from_tty);
    sr_scan_args (gr->ops->to_shortname, args);
    unpush_target (gr->ops);
  
    gr_settings = gr;
  
!   gr_set_dcache (dcache_init (gr->readfunc, gr->writefunc));
  
    if (sr_get_desc () != NULL)
      gr_close (0);
--- 154,171 ----
  void
  gr_open (char *args, int from_tty, struct gr_settings *gr)
  {
+   DCACHE *dcache;
+ 
    target_preopen (from_tty);
    sr_scan_args (gr->ops->to_shortname, args);
    unpush_target (gr->ops);
  
    gr_settings = gr;
  
!   if ((dcache = gr_get_dcache()) == NULL)
!     gr_set_dcache (dcache_init (gr->readfunc, gr->writefunc));
!   else
!     dcache_flush (dcache);
  
    if (sr_get_desc () != NULL)
      gr_close (0);
Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.19
diff -c -r1.19 remote.c
*** remote.c	2000/08/07 15:02:48	1.19
--- remote.c	2000/08/09 22:45:54
***************
*** 2057,2063 ****
  
    unpush_target (target);
  
!   remote_dcache = dcache_init (remote_read_bytes, remote_write_bytes);
  
    remote_desc = SERIAL_OPEN (name);
    if (!remote_desc)
--- 2057,2066 ----
  
    unpush_target (target);
  
!   if (!remote_dcache)
!     remote_dcache = dcache_init (remote_read_bytes, remote_write_bytes);
!   else
!     dcache_flush (remote_dcache);
  
    remote_desc = SERIAL_OPEN (name);
    if (!remote_desc)
***************
*** 5034,5040 ****
  
    unpush_target (&remote_cisco_ops);
  
!   remote_dcache = dcache_init (remote_read_bytes, remote_write_bytes);
  
    remote_desc = SERIAL_OPEN (name);
    if (!remote_desc)
--- 5037,5046 ----
  
    unpush_target (&remote_cisco_ops);
  
!   if (!remote_dcache)
!     remote_dcache = dcache_init (remote_read_bytes, remote_write_bytes);
!   else
!     dcache_flush (remote_dcache);
  
    remote_desc = SERIAL_OPEN (name);
    if (!remote_desc)


-- 
J.T. Conklin
RedBack Networks
From jimb@zwingli.cygnus.com Wed Aug 09 16:47:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Jimmy Guo <guo@cup.hp.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] language support: case sensitivity
Date: Wed, 09 Aug 2000 16:47:00 -0000
Message-id: <np66pa9fba.fsf@zwingli.cygnus.com>
References: <Pine.LNX.4.10.10008011521540.6905-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-08/msg00187.html
Content-length: 706

This is approved, with the following changes:

Scheme is not case-sensitive.  R5RS, section 2: "Upper and lower case
forms of a letter are never distinguished except within character and
string constants.  For example, Foo is the same identifier as FOO, and
#x1AB is the same number as #X1ab."

In lookup_symbol, please just go ahead and change the value of `name';
don't change every use of `name' to `copy'.  `copy' is a poor variable
name.  If it is necessary to keep the original, unmodified name
around, keep it in a variable named `original_name'.  (But I don't see
any remaining uses of `name', so I don't think this is necessary.)

Please update the comment above the call to check_field.

Thanks!
From dberlin@redhat.com Wed Aug 09 17:31:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Jimmy Guo <guo@cup.hp.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] language support: case sensitivity
Date: Wed, 09 Aug 2000 17:31:00 -0000
Message-id: <m3itta2bz0.fsf@dan2.cygnus.com>
References: <Pine.LNX.4.10.10008011521540.6905-100000@hpcll168.cup.hp.com> <np66pa9fba.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-08/msg00188.html
Content-length: 1070

Jim Blandy <jimb@zwingli.cygnus.com> writes:

Damnit, i'm five seconds away from submitting a patch to remove the
linear searches on C++ symbols completely, and I do it by always
demangling the name we search for, so i also make a copy of the name
in case demangling fails, and you go approve a patch that changes the
name.

--Dan
> This is approved, with the following changes:
> 
> Scheme is not case-sensitive.  R5RS, section 2: "Upper and lower case
> forms of a letter are never distinguished except within character and
> string constants.  For example, Foo is the same identifier as FOO, and
> #x1AB is the same number as #X1ab."
> 
> In lookup_symbol, please just go ahead and change the value of `name';
> don't change every use of `name' to `copy'.  `copy' is a poor variable
> name.  If it is necessary to keep the original, unmodified name
> around, keep it in a variable named `original_name'.  (But I don't see
> any remaining uses of `name', so I don't think this is necessary.)
> 
> Please update the comment above the call to check_field.
> 
> Thanks!