Re: [PRELIMINARY]: Patch to add bfd support for IBM s390

Re: [PRELIMINARY]: Patch to add bfd support for IBM s390

[DJBARROW]

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

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.

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

Re: [PRELIMINARY]: Patch to add bfd support for IBM s390

[Eli Zaretskii]

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

> From: DJBARROW@de.ibm.com
> Date: Fri, 25 Aug 2000 12:45:32 +0200
> 
> 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 ?

I think that watchpoint-related code in GDB improved _a lot_ since
v4.18, but I'm not sure how relevant these improvements are for the
S/390 port.  The watchpoint support is certainly much better for
x86-based targets, one of which I maintain.

If you can describe in more detail what problems did you see in v4.18,
it will be possible to tell you which problems are now resolved.
From DJBARROW@de.ibm.com Fri Aug 25 04:58:00 2000
From: DJBARROW@de.ibm.com
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sourceware.cygnus.com, nickc@cygnus.com, Michael Snyder <msnyder@redhat.com>
Subject: Re: [PRELIMINARY]: Patch to add bfd support for IBM s390
Date: Fri, 25 Aug 2000 04:58:00 -0000
Message-id: <C1256946.0041A357.00@d12mta09.de.ibm.com>
X-SW-Source: 2000-08/msg00313.html
Content-length: 706

If this code has improved my kludges are probably obselete.
To be honest it was a long time ago, it was primarily to do with
watchpoints set up in hw being
inconsistent with what info watchpoints said was active.

e.g. The watchpoint code cleaned the hardware breakpoints in the next run
while info watchpoints
still reported watchpoints active ( this kind of stuff ), unfortunately I
cant remember exactly just cast
asparagus.

 I'll do some testing over the next few days & if it still looks unhealthy
I'll start complaining.

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

Re: [PRELIMINARY]: Patch to add bfd support for IBM s390

[Michael Snyder]

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