From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Eager To: Richard Henderson Cc: "Chris G. Demetriou" , Andrew Cagney , 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:02:00 -0000 Message-id: <39919C53.91818790@eagercon.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> X-SW-Source: 2000-08/msg00177.html 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 To: Michael Eager Cc: "Chris G. Demetriou" , Andrew Cagney , 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: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 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 To: Jim Ingham Cc: Jimmy Guo , Andrew Cagney , Geoff Keating , 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: 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 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 * 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 To: Jim Ingham Cc: Jimmy Guo , Andrew Cagney , Geoff Keating , 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: 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 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 * 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" To: "DJ Delorie" Cc: , 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" To: Cc: 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 * 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 To: Jimmy Guo Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] language support: case sensitivity Date: Wed, 09 Aug 2000 16:47:00 -0000 Message-id: References: 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 To: Jim Blandy Cc: Jimmy Guo , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] language support: case sensitivity Date: Wed, 09 Aug 2000 17:31:00 -0000 Message-id: References: X-SW-Source: 2000-08/msg00188.html Content-length: 1070 Jim Blandy 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!