* Re: RFA: Recording MIPS ABI selection in binaries
[not found] ` <20000809104623.D28802@cygnus.com>
@ 2000-08-09 11:02 ` Michael Eager
0 siblings, 0 replies; 3+ messages in thread
From: Michael Eager @ 2000-08-09 11:02 UTC (permalink / raw)
To: Richard Henderson
Cc: Chris G. Demetriou, Andrew Cagney, Nick Clifton, gcc-patches,
gdb-patches
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!
^ permalink raw reply [flat|nested] 3+ messages in thread