Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@redhat.com>
To: DJBARROW@de.ibm.com
Cc: gdb-patches@sourceware.cygnus.com, schwidefsky@de.ibm.com
Subject: Re: [PRELIMINARY]: Patch to add bfd support for IBM s390
Date: Fri, 25 Aug 2000 11:02:00 -0000	[thread overview]
Message-ID: <39A6B4AC.7B65@redhat.com> (raw)
In-Reply-To: <C1256946.00620C31.00@d12mta09.de.ibm.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 20165 bytes --]

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 <msnyder@redhat.com> on 25.08.2000 19:35:34
> 
> Please respond to Michael Snyder <msnyder@redhat.com>
> 
> 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 <taylor@cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
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 <ezannoni@cygnus.com>
    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 <taylor@cygnus.com>
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  <taylor@texas.cygnus.com>

	* 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 <taylor@cygnus.com>
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  <taylor@texas.cygnus.com>

	* 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 <taylor@cygnus.com>
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  <taylor@texas.cygnus.com>

	* 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 <ezannoni@cygnus.com>
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  <ezannoni@kwikemart.cygnus.com>

	* 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;
     }
 }
 



       reply	other threads:[~2000-08-25 11:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <C1256946.00620C31.00@d12mta09.de.ibm.com>
2000-08-25 11:02 ` Michael Snyder [this message]
2000-08-25  3:46 DJBARROW
2000-08-25  4:09 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39A6B4AC.7B65@redhat.com \
    --to=msnyder@redhat.com \
    --cc=DJBARROW@de.ibm.com \
    --cc=gdb-patches@sourceware.cygnus.com \
    --cc=schwidefsky@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox