DJBARROW@de.ibm.com wrote: > > Sure thing I'm going back home till Thursday so apologies for the lack of > correspondance, > Is 5.0 adequete or should I move to something newer. If you can, it would be great if you would check out the up-to-the-minute sources from sourceware.cygnus.com and submit diffs against those. > D.J. Barrow Linux for S/390 kernel developer > eMail: djbarrow@de.ibm.com,barrow_dj@yahoo.com > Phone: +49-(0)7031-16-2583 > IBM Germany Lab, Schönaicherstr. 220, 71032 Böblingen > > Michael Snyder on 25.08.2000 19:35:34 > > Please respond to Michael Snyder > > To: Denis Joseph Barrow/Germany/Contr/IBM@IBMDE > cc: gdb-patches@sourceware.cygnus.com, Martin > Schwidefsky/Germany/IBM@IBMDE > Subject: Re: [PRELIMINARY]: Patch to add bfd support for IBM s390 > > --------------------------------------------------------------- > > DJBARROW@de.ibm.com wrote: > > > > Sorry I was referring to hardware watchpoints when making this comment. > > > > The breakpoint.c kludge I did as far as I remember is probably unwanted, > I > > just found that the > > hardware breakpoints in 4-18 were in absolutely terrible shape staying in > > when not wanted & > > disappearing for no reason, has this code improved ?, my clueless kludge > > improved the situation a tiny > > bit in the test cases I was playing with. > > I haven't had a chance to see whether the 5.0 code has improved > > substantially in my opinion > > this code needs a lot of attention by someone who knows it, if this code > > has improved recently > > please leave this out. > > How about if we remove it from your base port submission, > and revisit it if necessary after? From taylor@cygnus.com Fri Aug 25 11:34:00 2000 From: David Taylor To: Elena Zannoni Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [RFA]: search_symbols(in symtab.c) -- fix off by one error Date: Fri, 25 Aug 2000 11:34:00 -0000 Message-id: <200008251833.OAA05124@texas.cygnus.com> X-SW-Source: 2000-08/msg00321.html Content-length: 952 From: Elena Zannoni Date: Fri, 25 Aug 2000 11:56:20 -0400 (EDT) Yes, true. Approved. Now, though, there is another similar thing in symtab.c:symtab_symbol_info(). This function also defines an array and uses LABEL_NAMESPACE to access its elements. But it subtracts 1, so this is in sync: Thanks. symtab_symbol_info (regexp, kind, from_tty) char *regexp; namespace_enum kind; int from_tty; { static char *classnames[] = {"variable", "function", "type", "method"}; [....] printf_filtered (regexp ? "All %ss matching regular expression \"%s\":\n" : "All defined %ss:\n", classnames[(int) (kind - LABEL_NAMESPACE - 1)], regexp); [....] I wonder why LABEL_NAMESPACE was used at all. Can you fix this above occurrence as well, so it is all consistent? Done. I'll be committing it later today. Thanks Elena David From taylor@cygnus.com Fri Aug 25 14:07:00 2000 From: David Taylor To: gdb-patches@sourceware.cygnus.com Subject: [PATCH] symtab.c -- fix off by one bugs Date: Fri, 25 Aug 2000 14:07:00 -0000 Message-id: <200008252106.RAA05195@texas.cygnus.com> X-SW-Source: 2000-08/msg00322.html Content-length: 1873 The following patch has been applied to symtab.c: Fri Aug 25 12:11:21 2000 David Taylor * symtab.c (search_symbols): Fix off by one error in index for initializing variables ourtype, ourtype2, ourtype3, and ourtype4. (symtab_symbol_info): fix similar off by one error. Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.12 retrieving revision 1.13 diff -c -r1.12 -r1.13 *** symtab.c 2000/08/11 01:02:35 1.12 --- symtab.c 2000/08/25 20:51:19 1.13 *************** *** 3573,3582 **** if (kind < LABEL_NAMESPACE) error ("must search on specific namespace"); ! ourtype = types[(int) (kind - LABEL_NAMESPACE)]; ! ourtype2 = types2[(int) (kind - LABEL_NAMESPACE)]; ! ourtype3 = types3[(int) (kind - LABEL_NAMESPACE)]; ! ourtype4 = types4[(int) (kind - LABEL_NAMESPACE)]; sr = *matches = NULL; tail = NULL; --- 3573,3582 ---- if (kind < LABEL_NAMESPACE) error ("must search on specific namespace"); ! ourtype = types[(int) (kind - VARIABLES_NAMESPACE)]; ! ourtype2 = types2[(int) (kind - VARIABLES_NAMESPACE)]; ! ourtype3 = types3[(int) (kind - VARIABLES_NAMESPACE)]; ! ourtype4 = types4[(int) (kind - VARIABLES_NAMESPACE)]; sr = *matches = NULL; tail = NULL; *************** *** 3903,3909 **** printf_filtered (regexp ? "All %ss matching regular expression \"%s\":\n" : "All defined %ss:\n", ! classnames[(int) (kind - LABEL_NAMESPACE - 1)], regexp); for (p = symbols; p != NULL; p = p->next) { --- 3903,3909 ---- printf_filtered (regexp ? "All %ss matching regular expression \"%s\":\n" : "All defined %ss:\n", ! classnames[(int) (kind - VARIABLES_NAMESPACE)], regexp); for (p = symbols; p != NULL; p = p->next) { From taylor@cygnus.com Fri Aug 25 14:13:00 2000 From: David Taylor To: gdb-patches@sourceware.cygnus.com Subject: [PATCH] TARGET_ADDR_BIT Date: Fri, 25 Aug 2000 14:13:00 -0000 Message-id: <200008252113.RAA05208@texas.cygnus.com> X-SW-Source: 2000-08/msg00323.html Content-length: 5793 The following patch has been applied: [NOTE: I'm not including the diffs for gdbarch.c and gdbarch.h -- they can be generated from gdbarch.sh] Fri Aug 25 12:03:15 2000 David Taylor * gdbarch.sh (TARGET_ADDR_BIT): New macro for the number of bits in gdb's representation of a target address. * gdbarch.c, gdbarch.h: Regenerated. * gdbtypes.c (build_gdbtypes): Use TARGET_ADDR_BIT instead of TARGET_PTR_BIT when initializing builtin_type_CORE_ADDR. * printcmd.c (print_address_numeric): Use TARGET_ADDR_BIT instead of TARGET_PTR_BIT, because we're printing an address, not a pointer. Index: gdbarch.sh =================================================================== RCS file: /cvs/src/src/gdb/gdbarch.sh,v retrieving revision 1.40 retrieving revision 1.41 diff -c -r1.40 -r1.41 *** gdbarch.sh 2000/08/11 03:19:22 1.40 --- gdbarch.sh 2000/08/25 20:51:19 1.41 *************** *** 319,326 **** v::TARGET_DOUBLE_BIT:int:double_bit::::8 * sizeof (double):8*TARGET_CHAR_BIT::0 # Number of bits in a long double for the target machine. v::TARGET_LONG_DOUBLE_BIT:int:long_double_bit::::8 * sizeof (long double):2*TARGET_DOUBLE_BIT::0 ! # Number of bits in a pointer for the target machine v::TARGET_PTR_BIT:int:ptr_bit::::8 * sizeof (void*):TARGET_INT_BIT::0 # Number of bits in a BFD_VMA for the target object file format. v::TARGET_BFD_VMA_BIT:int:bfd_vma_bit::::8 * sizeof (void*):TARGET_ARCHITECTURE->bits_per_address::0 # --- 319,336 ---- v::TARGET_DOUBLE_BIT:int:double_bit::::8 * sizeof (double):8*TARGET_CHAR_BIT::0 # Number of bits in a long double for the target machine. v::TARGET_LONG_DOUBLE_BIT:int:long_double_bit::::8 * sizeof (long double):2*TARGET_DOUBLE_BIT::0 ! # For most targets, a pointer on the target and its representation as an ! # address in GDB have the same size and "look the same". For such a ! # target, you need only set TARGET_PTR_BIT / ptr_bit and TARGET_ADDR_BIT ! # / addr_bit will be set from it. ! # ! # If TARGET_PTR_BIT and TARGET_ADDR_BIT are different, you'll probably ! # also need to set POINTER_TO_ADDRESS and ADDRESS_TO_POINTER as well. ! # ! # ptr_bit is the size of a pointer on the target v::TARGET_PTR_BIT:int:ptr_bit::::8 * sizeof (void*):TARGET_INT_BIT::0 + # addr_bit is the size of a target address as represented in gdb + v::TARGET_ADDR_BIT:int:addr_bit::::8 * sizeof (void*):0:TARGET_PTR_BIT: # Number of bits in a BFD_VMA for the target object file format. v::TARGET_BFD_VMA_BIT:int:bfd_vma_bit::::8 * sizeof (void*):TARGET_ARCHITECTURE->bits_per_address::0 # *************** *** 515,527 **** /* This file was created with the aid of \`\`gdbarch.sh''. ! The bourn shell script \`\`gdbarch.sh'' creates the files \`\`new-gdbarch.c'' and \`\`new-gdbarch.h and then compares them against the existing \`\`gdbarch.[hc]''. Any differences found being reported. If editing this file, please also run gdbarch.sh and merge any ! changes into that script. Conversely, when makeing sweeping changes to this file, modifying gdbarch.sh and using its output may prove easier. */ --- 525,537 ---- /* This file was created with the aid of \`\`gdbarch.sh''. ! The Bourne shell script \`\`gdbarch.sh'' creates the files \`\`new-gdbarch.c'' and \`\`new-gdbarch.h and then compares them against the existing \`\`gdbarch.[hc]''. Any differences found being reported. If editing this file, please also run gdbarch.sh and merge any ! changes into that script. Conversely, when making sweeping changes to this file, modifying gdbarch.sh and using its output may prove easier. */ Index: gdbtypes.c =================================================================== RCS file: /cvs/src/src/gdb/gdbtypes.c,v retrieving revision 1.12 retrieving revision 1.13 diff -c -r1.12 -r1.13 *** gdbtypes.c 2000/07/30 01:48:25 1.12 --- gdbtypes.c 2000/08/25 20:51:19 1.13 *************** *** 2929,2935 **** though the two can be different (cf d10v) */ builtin_type_ptr = make_pointer_type (builtin_type_void, NULL); builtin_type_CORE_ADDR = ! init_type (TYPE_CODE_INT, TARGET_PTR_BIT / 8, TYPE_FLAG_UNSIGNED, "__CORE_ADDR", (struct objfile *) NULL); builtin_type_bfd_vma = --- 2929,2935 ---- though the two can be different (cf d10v) */ builtin_type_ptr = make_pointer_type (builtin_type_void, NULL); builtin_type_CORE_ADDR = ! init_type (TYPE_CODE_INT, TARGET_ADDR_BIT / 8, TYPE_FLAG_UNSIGNED, "__CORE_ADDR", (struct objfile *) NULL); builtin_type_bfd_vma = Index: printcmd.c =================================================================== RCS file: /cvs/src/src/gdb/printcmd.c,v retrieving revision 1.12 retrieving revision 1.13 diff -c -r1.12 -r1.13 *** printcmd.c 2000/07/30 01:48:26 1.12 --- printcmd.c 2000/08/25 20:51:19 1.13 *************** *** 726,734 **** kept in the least significant bits of ADDR - the upper bits were either zero or sign extended. Should ADDRESS_TO_POINTER() or some ADDRESS_TO_PRINTABLE() be used to do the conversion? */ ! int ptr_bit = TARGET_PTR_BIT; ! if (ptr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT)) ! addr &= ((CORE_ADDR) 1 << ptr_bit) - 1; print_longest (stream, 'x', use_local, (ULONGEST) addr); } --- 726,734 ---- kept in the least significant bits of ADDR - the upper bits were either zero or sign extended. Should ADDRESS_TO_POINTER() or some ADDRESS_TO_PRINTABLE() be used to do the conversion? */ ! int addr_bit = TARGET_ADDR_BIT; ! if (addr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT)) ! addr &= ((CORE_ADDR) 1 << addr_bit) - 1; print_longest (stream, 'x', use_local, (ULONGEST) addr); } From taylor@cygnus.com Fri Aug 25 14:17:00 2000 From: David Taylor To: gdb-patches@sourceware.cygnus.com Subject: [PATCH] register_changed Date: Fri, 25 Aug 2000 14:17:00 -0000 Message-id: <200008252116.RAA05221@texas.cygnus.com> X-SW-Source: 2000-08/msg00324.html Content-length: 1338 The following patch has been applied: Fri Aug 25 16:57:05 2000 David Taylor * regcache.c (register_changed): New function. * value.h: Declare it. Index: regcache.c =================================================================== RCS file: /cvs/src/src/gdb/regcache.c,v retrieving revision 1.8 retrieving revision 1.9 diff -c -r1.8 -r1.9 *** regcache.c 2000/08/11 19:09:55 1.8 --- regcache.c 2000/08/25 21:03:00 1.9 *************** *** 68,73 **** --- 68,82 ---- return register_valid[regnum]; } + /* REGISTER_CHANGED + + invalidate a single register REGNUM in the cache */ + void + register_changed (int regnum) + { + register_valid[regnum] = 0; + } + /* FIND_SAVED_REGISTER () Return the address in which frame FRAME's value of register REGNUM Index: value.h =================================================================== RCS file: /cvs/src/src/gdb/value.h,v retrieving revision 1.8 retrieving revision 1.9 diff -c -r1.8 -r1.9 *** value.h 2000/08/16 08:03:43 1.8 --- value.h 2000/08/25 21:03:00 1.9 *************** *** 490,495 **** --- 490,497 ---- extern int register_cached (int regno); + extern void register_changed (int regnum); + extern void get_saved_register (char *raw_buffer, int *optimized, CORE_ADDR * addrp, struct frame_info *frame, From ezannoni@cygnus.com Fri Aug 25 18:42:00 2000 From: Elena Zannoni To: gdb-patches@sources.redhat.com Cc: dave@hiauly1.hia.nrc.ca Subject: [PATCH] Fix ANOFFSET problems Date: Fri, 25 Aug 2000 18:42:00 -0000 Message-id: <14759.8317.764597.718666@kwikemart.cygnus.com> X-SW-Source: 2000-08/msg00325.html Content-length: 6814 Dave, please try these fixes. Sorry about that. Will commit tomorrow. Elena 2000-08-25 Elena Zannoni * pa64solib.c (pa64_solib_load_symbols): Don't use ANOFFSET as an lvalue. * xcoffread.c (xcoff_symfile_offsets): Ditto * somsolib.c (som_solib_section_offsets): Ditto. * somread.c (som_symfile_offsets): Ditto. * rs6000-nat.c (vmap_symtab): Ditto. * remote-vx.c (vx_add_symbols): Ditto. * remote-os9k.c (rombug_wait): Ditto. Index: pa64solib.c =================================================================== RCS file: /cvs/src/src/gdb/pa64solib.c,v retrieving revision 1.6 diff -c -u -p -r1.6 pa64solib.c --- pa64solib.c 2000/08/09 20:09:01 1.6 +++ pa64solib.c 2000/08/26 01:25:07 @@ -319,9 +319,9 @@ pa64_solib_load_symbols (struct so_list return; } - ANOFFSET (so->objfile->section_offsets, SECT_OFF_TEXT (so->objfile)) + (so->objfile->section_offsets)->offsets[SECT_OFF_TEXT (so->objfile)] = so->pa64_solib_desc.text_base; - ANOFFSET (so->objfile->section_offsets, SECT_OFF_DATA (so->objfile)) + (so->objfile->section_offsets)->offsets[SECT_OFF_DATA (so->objfile)] = so->pa64_solib_desc.data_base; /* Relocate all the sections based on where they got loaded. */ Index: remote-os9k.c =================================================================== RCS file: /cvs/src/src/gdb/remote-os9k.c,v retrieving revision 1.4 diff -c -u -p -r1.4 remote-os9k.c --- remote-os9k.c 2000/07/30 01:48:26 1.4 +++ remote-os9k.c 2000/08/26 01:25:07 @@ -493,8 +493,8 @@ rombug_wait (int pid, struct target_wait new_symfile_objfile (obj_sec->objfile, 1, 0); offs = (struct section_offsets *) alloca (SIZEOF_SECTION_OFFSETS); memcpy (offs, symfile_objfile->section_offsets, SIZEOF_SECTION_OFFSETS); - ANOFFSET (offs, SECT_OFF_DATA (symfile_objfile)) = addr; - ANOFFSET (offs, SECT_OFF_BSS (symfile_objfile)) = addr; + offs->offsets[SECT_OFF_DATA (symfile_objfile)] = addr; + offs->offsets[SECT_OFF_BSS (symfile_objfile)] = addr; objfile_relocate (symfile_objfile, offs); } Index: remote-vx.c =================================================================== RCS file: /cvs/src/src/gdb/remote-vx.c,v retrieving revision 1.6 diff -c -u -p -r1.6 remote-vx.c --- remote-vx.c 2000/08/02 14:52:10 1.6 +++ remote-vx.c 2000/08/26 01:25:08 @@ -685,9 +685,9 @@ vx_add_symbols (char *name, int from_tty bfd_map_over_sections (objfile->obfd, find_sect, &ss); /* Both COFF and b.out frontends use these SECT_OFF_* values. */ - ANOFFSET (offs, SECT_OFF_TEXT (objfile)) = text_addr - ss.text_start; - ANOFFSET (offs, SECT_OFF_DATA (objfile)) = data_addr - ss.data_start; - ANOFFSET (offs, SECT_OFF_BSS (objfile)) = bss_addr - ss.bss_start; + offs->offsets[SECT_OFF_TEXT (objfile)] = text_addr - ss.text_start; + offs->offsets[SECT_OFF_DATA (objfile)] = data_addr - ss.data_start; + offs->offsets[SECT_OFF_BSS (objfile)] = bss_addr - ss.bss_start; objfile_relocate (objfile, offs); } Index: rs6000-nat.c =================================================================== RCS file: /cvs/src/src/gdb/rs6000-nat.c,v retrieving revision 1.8 diff -c -u -p -r1.8 rs6000-nat.c --- rs6000-nat.c 2000/08/11 01:30:11 1.8 +++ rs6000-nat.c 2000/08/26 01:25:08 @@ -609,13 +609,13 @@ vmap_symtab (struct vmap *vp) new_offsets = (struct section_offsets *) alloca (SIZEOF_SECTION_OFFSETS); for (i = 0; i < objfile->num_sections; ++i) - ANOFFSET (new_offsets, i) = ANOFFSET (objfile->section_offsets, i); + new_offsets->offsets[i] = ANOFFSET (objfile->section_offsets, i); /* The symbols in the object file are linked to the VMA of the section, relocate them VMA relative. */ - ANOFFSET (new_offsets, SECT_OFF_TEXT (objfile)) = vp->tstart - vp->tvma; - ANOFFSET (new_offsets, SECT_OFF_DATA (objfile)) = vp->dstart - vp->dvma; - ANOFFSET (new_offsets, SECT_OFF_BSS (objfile)) = vp->dstart - vp->dvma; + new_offsets->offsets[SECT_OFF_TEXT (objfile)] = vp->tstart - vp->tvma; + new_offsets->offsets[SECT_OFF_DATA (objfile)] = vp->dstart - vp->dvma; + new_offsets->offsets[SECT_OFF_BSS (objfile)] = vp->dstart - vp->dvma; objfile_relocate (objfile, new_offsets); } Index: somread.c =================================================================== RCS file: /cvs/src/src/gdb/somread.c,v retrieving revision 1.6 diff -c -u -p -r1.6 somread.c --- somread.c 2000/07/30 01:48:27 1.6 +++ somread.c 2000/08/26 01:25:08 @@ -477,7 +477,7 @@ som_symfile_offsets (struct objfile *obj text_addr = addrs->other[i].addr; for (i = 0; i < SECT_OFF_MAX; i++) - ANOFFSET (objfile->section_offsets, i) = text_addr; + (objfile->section_offsets)->offsets[i] = text_addr; } } Index: somsolib.c =================================================================== RCS file: /cvs/src/src/gdb/somsolib.c,v retrieving revision 1.5 diff -c -u -p -r1.5 somsolib.c --- somsolib.c 2000/07/30 01:48:27 1.5 +++ somsolib.c 2000/08/26 01:25:09 @@ -1378,10 +1378,10 @@ som_solib_section_offsets (struct objfil asection *private_section; /* The text offset is easy. */ - ANOFFSET (offsets, SECT_OFF_TEXT (objfile)) + offsets->offsets[SECT_OFF_TEXT (objfile)] = (so_list->som_solib.text_addr - so_list->som_solib.text_link_addr); - ANOFFSET (offsets, SECT_OFF_RODATA (objfile)) + offsets->offsets[SECT_OFF_RODATA (objfile)] = ANOFFSET (offsets, SECT_OFF_TEXT (objfile)); /* We should look at presumed_dp in the SOM header, but @@ -1391,13 +1391,13 @@ som_solib_section_offsets (struct objfil if (!private_section) { warning ("Unable to find $PRIVATE$ in shared library!"); - ANOFFSET (offsets, SECT_OFF_DATA (objfile)) = 0; - ANOFFSET (offsets, SECT_OFF_BSS (objfile)) = 0; + offsets->offsets[SECT_OFF_DATA (objfile)] = 0; + offsets->offsets[SECT_OFF_BSS (objfile)] = 0; return 1; } - ANOFFSET (offsets, SECT_OFF_DATA (objfile)) + offsets->offsets[SECT_OFF_DATA (objfile)] = (so_list->som_solib.data_start - private_section->vma); - ANOFFSET (offsets, SECT_OFF_BSS (objfile)) + offsets->offsets[SECT_OFF_BSS (objfile)] = ANOFFSET (offsets, SECT_OFF_DATA (objfile)); return 1; } Index: xcoffread.c =================================================================== RCS file: /cvs/src/src/gdb/xcoffread.c,v retrieving revision 1.8 diff -c -u -p -r1.8 xcoffread.c --- xcoffread.c 2000/08/07 15:16:15 1.8 +++ xcoffread.c 2000/08/26 01:25:09 @@ -2744,7 +2744,7 @@ xcoff_symfile_offsets (struct objfile *o sensibly), so just ignore the addr parameter and use 0. rs6000-nat.c will set the correct section offsets via objfile_relocate. */ - ANOFFSET (objfile->section_offsets, i) = 0; + (objfile->section_offsets)->offsets[i] = 0; } }