bfd_read and bfd_write

bfd_read and bfd_write

[Alan Modra]

I have a (rather large) patch to clean up a few things in bfd that I'd
like to apply in the next day or so, but first thought I'd better give
people fair warning and a chance to object.

One of the changes I've made is to bfd_read, and similarly bfd_write.

 bfd_size_type
-bfd_read (ptr, size, nitems, abfd)
+bfd_read (ptr, size, abfd)
      PTR ptr;
      bfd_size_type size;
-     bfd_size_type nitems;
      bfd *abfd;

Why the change?  Well, in having both "size" and "nitems", you'd expect
bfd_read to behave like fread, but it doesn't.  bfd_read returns
"size * nitems" on success, whereas fread returns "nitems".  Additionally,
many places in bfd swap the "size" and "nitems" args, and technically
we should always have size == 1 since we are operating on files of bytes.
This doesn't really matter as bfd_read does the multiplication and
passes size == 1 down to fread, but we're breaking the fread abstraction.

This change will of course break gdb, for which I have patches, and
any uncontributed ports.

Comments/flames?

Alan

Re: bfd_read and bfd_write

[Andrew Cagney]

> I have a (rather large) patch to clean up a few things in bfd that I'd
> like to apply in the next day or so, but first thought I'd better give
> people fair warning and a chance to object.
> 
> One of the changes I've made is to bfd_read, and similarly bfd_write.
> 
>  bfd_size_type
> -bfd_read (ptr, size, nitems, abfd)
> +bfd_read (ptr, size, abfd)
>       PTR ptr;
>       bfd_size_type size;
> -     bfd_size_type nitems;
>       bfd *abfd;


rather than change the function signature, why not introduce a new 
interface and then deprecate the old one?


> 

Re: bfd_read and bfd_write

[Richard Henderson]

On Wed, Sep 05, 2001 at 12:45:10PM -0400, Andrew Cagney wrote:
> rather than change the function signature, why not introduce a new 
> interface and then deprecate the old one?

Because then you'll never get rid of the old interface.
BFD already has way too much cruft as it is.


r~

Re: bfd_read and bfd_write

[Andrew Cagney]

> On Wed, Sep 05, 2001 at 12:45:10PM -0400, Andrew Cagney wrote:
> 
>> rather than change the function signature, why not introduce a new 
>> interface and then deprecate the old one?
> 
> 
> Because then you'll never get rid of the old interface.
why not introduce the new _external_ interface, go around eliminating 
all known uses of the old.  once done (new release made?) zap the old 
interface.  a common pratice is to add code to the old interface to 
issue a warning the first time it is called.

alan's basic problem of needing to co-ordinate everything so it can all 
happen at once just goes away.

it also covers the k&r problem - you cant rely on a k&r compiler to 
report parameter mismatches.

andrew

Re: bfd_read and bfd_write

[Alan Modra]

On Wed, Sep 05, 2001 at 08:26:26PM -0400, Andrew Cagney wrote:
> > On Wed, Sep 05, 2001 at 12:45:10PM -0400, Andrew Cagney wrote:
> > 
> >> rather than change the function signature, why not introduce a new 
> >> interface and then deprecate the old one?
> > 
> > 
> > Because then you'll never get rid of the old interface.
> why not introduce the new _external_ interface, go around eliminating 
> all known uses of the old.  once done (new release made?) zap the old 
> interface.  a common pratice is to add code to the old interface to 
> issue a warning the first time it is called.
> 
> alan's basic problem of needing to co-ordinate everything so it can all 
> happen at once just goes away.

I have patches for all of bfd, gas, gdb.  Shouldn't be more than half an
hour checking them all in, unless my net connection breaks or something.
I tend to agree with rth that it's better to break things temporarily
and force use of a new interface than leave compatibility code around,
unless it's a major effort to change over.

Of course, you could force me to leave the old code in by witholding
permission to make the changes to gdb.  :-)

> it also covers the k&r problem - you cant rely on a k&r compiler to 
> report parameter mismatches.

That's the other part of my bfd patchset:  Fixing all the -Wconversion
errors that gcc reports.  I've done 32 bit native, 32 -> 64 bit xcompiles,
with 64 bit native and 64 -> 32 bit xcompiles yet to do.  The last two
cases should catch all the int/long mismatches, the first two catch
int/long vs. bfd_vma/bfd_size_type etc. mismatches.

Alan

Re: bfd_read and bfd_write

[Andrew Cagney]

 > I have patches for all of bfd, gas, gdb.  Shouldn't be more than half an
 > hour checking them all in, unless my net connection breaks or something.
 > I tend to agree with rth that it's better to break things temporarily
 > and force use of a new interface than leave compatibility code around,
 > unless it's a major effort to change over.
 >
 > Of course, you could force me to leave the old code in by witholding
 > permission to make the changes to gdb.   [:-)]

could i suggest taking a step back and deciding what bfd's policy is 
going to be on public / external interfaces.  remember, bfd is a library 
used by more than gdb and the other code immediately to hand.  i don't 
think changing public / external interfaces should be taken lightly (are 
you bumping the shlib version?).

i'd strongly recommend at least changing the function name as well as 
the function signature - that way old code can't pick up the new 
interface.  i'd also prefer to have the old interface around for at 
least a wee bit (allow mix 'n' match) of new bfd, old ... and give the 
change a chance to propogate / settle.  this also guarentees that gdb 
continues to _always_ be buildable.  i'm also some what puzzled as to 
why this all has to be done as a single jumbo patch, three separate 
patches (add new, change, delete old) are surely easier.

if you want, i can also add a check to gdb that ensures that the old 
function isn't used.

enjoy
	andrew

Re: bfd_read and bfd_write

[Hans-Peter Nilsson]

On Wed, 5 Sep 2001, Alan Modra wrote:
> This change will of course break gdb, for which I have patches, and
> any uncontributed ports.
>
> Comments/flames?

It's a simple, mechanical change that gets rid of a redundant
parameter.  Go wild!

If you go for new names anyway, I suggest bfd_bread and
bfd_bwrite.

brgds, H-P
PS.  Also speaking from having an uncontributed port.

Re: bfd_read and bfd_write

[Alan Modra]

On Wed, Sep 05, 2001 at 11:13:32PM -0400, Hans-Peter Nilsson wrote:
> 
> If you go for new names anyway, I suggest bfd_bread and
> bfd_bwrite.

I'll probably go with this idea.  Anyone for bfd_bread and bfd_butter? :-)

Re: bfd_read and bfd_write

[Andreas Jaeger]

Alan Modra <amodra@bigpond.net.au> writes:

>> it also covers the k&r problem - you cant rely on a k&r compiler to 
>> report parameter mismatches.
>
> That's the other part of my bfd patchset:  Fixing all the -Wconversion
> errors that gcc reports.  I've done 32 bit native, 32 -> 64 bit xcompiles,
> with 64 bit native and 64 -> 32 bit xcompiles yet to do.  The last two
> cases should catch all the int/long mismatches, the first two catch
> int/long vs. bfd_vma/bfd_size_type etc. mismatches.

Have you done --enable-targets=all --enable-64-bit-bfd builds - and
fixed all those warnings?  Wow!  I'm looking forward to that patch.

In that case we should add -Wconversion to build_warnings.

thanks,
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: bfd_read and bfd_write

[Alan Modra]

On Thu, Sep 06, 2001 at 08:15:23AM +0200, Andreas Jaeger wrote:
> Alan Modra <amodra@bigpond.net.au> writes:
> 
> Have you done --enable-targets=all --enable-64-bit-bfd builds - and
> fixed all those warnings?  Wow!  I'm looking forward to that patch.

Yes.

> In that case we should add -Wconversion to build_warnings.

No, because of zillions of warnings courtesy of glibc like:

/usr/include/bits/string2.h: In function `__strsep_g':
/usr/include/bits/string2.h:1171: warning: passing arg 2 of `__strpbrk_c2' with different width due to prototype
/usr/include/bits/string2.h:1171: warning: passing arg 3 of `__strpbrk_c2' with different width due to prototype
/usr/include/bits/string2.h:1171: warning: passing arg 2 of `__strpbrk_c3' with different width due to prototype
/usr/include/bits/string2.h:1171: warning: passing arg 3 of `__strpbrk_c3' with different width due to prototype
/usr/include/bits/string2.h:1171: warning: passing arg 4 of `__strpbrk_c3' with different width due to prototype

Alan

Re: bfd_read and bfd_write

[Nick Clifton]

Hi Andrew, Hi Alan,

> could i suggest taking a step back and deciding what bfd's policy is
> going to be on public / external interfaces.  remember, bfd is a
> library used by more than gdb and the other code immediately to hand.
> i don't think changing public / external interfaces should be taken
> lightly

I agree.  In this case since we are changing the interface to bfd we
ought to take some time to give other users of the library a chance to
upgrade their software.

I like the idea of adding the new interface, with new function names,
and a warning message being generated if the old interface is used, as
part of the current CVS sources/forthcoming release.  Then in the
release after that, we can remove the old interface.

It takes longer this way I know, but I think that we ought to give
other binary tool developers a chance to change their software.

Cheers
        Nick

Re: bfd_read and bfd_write

[Jim Blandy]

Hans-Peter Nilsson <hp@bitrange.com> writes:
> If you go for new names anyway, I suggest bfd_bread and

... bfd_butter?  bfd_wine and bfd_thou?

Re: bfd_read and bfd_write

[Hans-Peter Nilsson]

On 9 Sep 2001, Jim Blandy wrote:
> Hans-Peter Nilsson <hp@bitrange.com> writes:
> > If you go for new names anyway, I suggest bfd_bread and
>
> ... bfd_butter?  bfd_wine and bfd_thou?

If it didn't have a slightly wacky twist, it wouldn't be a good
name. :-)  I still don't get the original BFD one, though.

brgds, H-P

Re: bfd_read and bfd_write

[Ian Lance Taylor]

Hans-Peter Nilsson <hp@bitrange.com> writes:

> On 9 Sep 2001, Jim Blandy wrote:
> > Hans-Peter Nilsson <hp@bitrange.com> writes:
> > > If you go for new names anyway, I suggest bfd_bread and
> >
> > ... bfd_butter?  bfd_wine and bfd_thou?
> 
> If it didn't have a slightly wacky twist, it wouldn't be a good
> name. :-)  I still don't get the original BFD one, though.

Which original BFD one?

Ian

Re: bfd_read and bfd_write

[Hans-Peter Nilsson]

On 10 Sep 2001, Ian Lance Taylor wrote:
> Hans-Peter Nilsson <hp@bitrange.com> writes:
> > If it didn't have a slightly wacky twist, it wouldn't be a good
> > name. :-)  I still don't get the original BFD one, though.
>
> Which original BFD one?

That BFD (also) alludes to something other than Binary File
Descriptor, because of this passage from bfd/doc/bfd.texinfo,
node History:
"The name came from a conversation David Wallace was having with
 Richard Stallman about the library: RMS said that it would be
 quite hard---David said ``BFD''.  Stallman was right, but the
 name stuck."
Me not native speaker.  Could it be as profane as "big f..ng deal"?

brgds, H-P

Re: bfd_read and bfd_write

[Ian Lance Taylor]

Hans-Peter Nilsson <hp@bitrange.com> writes:

> On 10 Sep 2001, Ian Lance Taylor wrote:
> > Hans-Peter Nilsson <hp@bitrange.com> writes:
> > > If it didn't have a slightly wacky twist, it wouldn't be a good
> > > name. :-)  I still don't get the original BFD one, though.
> >
> > Which original BFD one?
> 
> That BFD (also) alludes to something other than Binary File
> Descriptor, because of this passage from bfd/doc/bfd.texinfo,
> node History:
> "The name came from a conversation David Wallace was having with
>  Richard Stallman about the library: RMS said that it would be
>  quite hard---David said ``BFD''.  Stallman was right, but the
>  name stuck."
> Me not native speaker.  Could it be as profane as "big f..ng deal"?

It could be and it is.

Ian

Re: bfd_read and bfd_write

[Alan Modra]

On Thu, Sep 06, 2001 at 06:32:13PM +0100, Nick Clifton wrote:
> I like the idea of adding the new interface, with new function names,
> and a warning message being generated if the old interface is used, as
> part of the current CVS sources/forthcoming release.  Then in the
> release after that, we can remove the old interface.

Here is the patch to gdb/ to move over to the new bfd_bread and bfd_bwrite
functions, which have just been committed.

	* coffread.c: Replace all occurrences of bfd_read with bfd_bread.
	* dbxread.c: Likewise.
	* dwarf2read.c: Likewise.
	* dwarfread.c: Likewise.
	* somread.c: Likewise.
	* ultra3-nat.c: Likewise.
	* xcoffread.c: Likewise.

OK to apply?

-- 
Alan Modra

Index: coffread.c
===================================================================
RCS file: /cvs/src/src/gdb/coffread.c,v
retrieving revision 1.19
diff -u -p -r1.19 coffread.c
--- coffread.c	2001/07/01 10:04:58	1.19
+++ coffread.c	2001/09/18 10:22:49
@@ -1154,18 +1154,18 @@ read_one_sym (register struct coff_symbo
   int i;
 
   cs->c_symnum = symnum;
-  bfd_read (temp_sym, local_symesz, 1, nlist_bfd_global);
+  bfd_bread (temp_sym, local_symesz, nlist_bfd_global);
   bfd_coff_swap_sym_in (symfile_bfd, temp_sym, (char *) sym);
   cs->c_naux = sym->n_numaux & 0xff;
   if (cs->c_naux >= 1)
     {
-      bfd_read (temp_aux, local_auxesz, 1, nlist_bfd_global);
+      bfd_bread (temp_aux, local_auxesz, nlist_bfd_global);
       bfd_coff_swap_aux_in (symfile_bfd, temp_aux, sym->n_type, sym->n_sclass,
 			    0, cs->c_naux, (char *) aux);
       /* If more than one aux entry, read past it (only the first aux
          is important). */
       for (i = 1; i < cs->c_naux; i++)
-	bfd_read (temp_aux, local_auxesz, 1, nlist_bfd_global);
+	bfd_bread (temp_aux, local_auxesz, nlist_bfd_global);
     }
   cs->c_name = getsymname (sym);
   cs->c_value = sym->n_value;
@@ -1232,7 +1232,7 @@ init_stringtab (bfd *abfd, long offset)
   if (bfd_seek (abfd, offset, 0) < 0)
     return -1;
 
-  val = bfd_read ((char *) lengthbuf, sizeof lengthbuf, 1, abfd);
+  val = bfd_bread ((char *) lengthbuf, sizeof lengthbuf, abfd);
   length = bfd_h_get_32 (symfile_bfd, lengthbuf);
 
   /* If no string table is needed, then the file may end immediately
@@ -1247,7 +1247,8 @@ init_stringtab (bfd *abfd, long offset)
   if (length == sizeof length)	/* Empty table -- just the count */
     return 0;
 
-  val = bfd_read (stringtab + sizeof lengthbuf, length - sizeof lengthbuf, 1, abfd);
+  val = bfd_bread (stringtab + sizeof lengthbuf, length - sizeof lengthbuf,
+		   abfd);
   if (val != length - sizeof lengthbuf || stringtab[length - 1] != '\0')
     return -1;
 
@@ -1346,7 +1347,7 @@ init_lineno (bfd *abfd, long offset, int
   /* Allocate the desired table, plus a sentinel */
   linetab = (char *) xmalloc (size + local_linesz);
 
-  val = bfd_read (linetab, size, 1, abfd);
+  val = bfd_bread (linetab, size, abfd);
   if (val != size)
     return -1;
 
Index: dbxread.c
===================================================================
RCS file: /cvs/src/src/gdb/dbxread.c,v
retrieving revision 1.23
diff -u -p -r1.23 dbxread.c
--- dbxread.c	2001/09/06 20:50:48	1.23
+++ dbxread.c	2001/09/18 10:22:53
@@ -700,7 +700,7 @@ dbx_symfile_init (struct objfile *objfil
 	perror_with_name (name);
 
       memset ((PTR) size_temp, 0, sizeof (size_temp));
-      val = bfd_read ((PTR) size_temp, sizeof (size_temp), 1, sym_bfd);
+      val = bfd_bread ((PTR) size_temp, sizeof (size_temp), sym_bfd);
       if (val < 0)
 	{
 	  perror_with_name (name);
@@ -739,8 +739,9 @@ dbx_symfile_init (struct objfile *objfil
 	  val = bfd_seek (sym_bfd, STRING_TABLE_OFFSET, SEEK_SET);
 	  if (val < 0)
 	    perror_with_name (name);
-	  val = bfd_read (DBX_STRINGTAB (objfile), DBX_STRINGTAB_SIZE (objfile), 1,
-			  sym_bfd);
+	  val = bfd_bread (DBX_STRINGTAB (objfile),
+			   DBX_STRINGTAB_SIZE (objfile),
+			   sym_bfd);
 	  if (val != DBX_STRINGTAB_SIZE (objfile))
 	    perror_with_name (name);
 	}
@@ -931,7 +932,7 @@ fill_symbuf (bfd *sym_bfd)
 	count = sizeof (symbuf);
     }
 
-  nbytes = bfd_read ((PTR) symbuf, count, 1, sym_bfd);
+  nbytes = bfd_bread ((PTR) symbuf, count, sym_bfd);
   if (nbytes < 0)
     perror_with_name (bfd_get_filename (sym_bfd));
   else if (nbytes == 0)
@@ -2501,7 +2502,7 @@ coffstab_build_psymtabs (struct objfile 
   val = bfd_seek (sym_bfd, stabstroffset, SEEK_SET);
   if (val < 0)
     perror_with_name (name);
-  val = bfd_read (DBX_STRINGTAB (objfile), stabstrsize, 1, sym_bfd);
+  val = bfd_bread (DBX_STRINGTAB (objfile), stabstrsize, sym_bfd);
   if (val != stabstrsize)
     perror_with_name (name);
 
@@ -2597,7 +2598,7 @@ elfstab_build_psymtabs (struct objfile *
   val = bfd_seek (sym_bfd, stabstroffset, SEEK_SET);
   if (val < 0)
     perror_with_name (name);
-  val = bfd_read (DBX_STRINGTAB (objfile), stabstrsize, 1, sym_bfd);
+  val = bfd_bread (DBX_STRINGTAB (objfile), stabstrsize, sym_bfd);
   if (val != stabstrsize)
     perror_with_name (name);
 
Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.31
diff -u -p -r1.31 dwarf2read.c
--- dwarf2read.c	2001/09/05 02:13:11	1.31
+++ dwarf2read.c	2001/09/18 10:22:58
@@ -3030,7 +3030,7 @@ dwarf2_read_section (struct objfile *obj
 
   buf = (char *) obstack_alloc (&objfile->psymbol_obstack, size);
   if ((bfd_seek (abfd, offset, SEEK_SET) != 0) ||
-      (bfd_read (buf, size, 1, abfd) != size))
+      (bfd_bread (buf, size, abfd) != size))
     {
       buf = NULL;
       error ("Dwarf Error: Can't read DWARF data from '%s'",
Index: dwarfread.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarfread.c,v
retrieving revision 1.8
diff -u -p -r1.8 dwarfread.c
--- dwarfread.c	2001/09/05 02:13:11	1.8
+++ dwarfread.c	2001/09/18 10:23:01
@@ -695,7 +695,7 @@ dwarf_build_psymtabs (struct objfile *ob
   dbbase = xmalloc (dbsize);
   dbroff = 0;
   if ((bfd_seek (abfd, dbfoff, SEEK_SET) != 0) ||
-      (bfd_read (dbbase, dbsize, 1, abfd) != dbsize))
+      (bfd_bread (dbbase, dbsize, abfd) != dbsize))
     {
       xfree (dbbase);
       error ("can't read DWARF data from '%s'", bfd_get_filename (abfd));
@@ -2269,7 +2269,7 @@ read_ofile_symtab (struct partial_symtab
   base_section_offsets = pst->section_offsets;
   baseaddr = ANOFFSET (pst->section_offsets, 0);
   if (bfd_seek (abfd, foffset, SEEK_SET) ||
-      (bfd_read (dbbase, dbsize, 1, abfd) != dbsize))
+      (bfd_bread (dbbase, dbsize, abfd) != dbsize))
     {
       xfree (dbbase);
       error ("can't read DWARF data");
@@ -2285,8 +2285,8 @@ read_ofile_symtab (struct partial_symtab
   if (LNFOFF (pst))
     {
       if (bfd_seek (abfd, LNFOFF (pst), SEEK_SET) ||
-	  (bfd_read ((PTR) lnsizedata, sizeof (lnsizedata), 1, abfd) !=
-	   sizeof (lnsizedata)))
+	  (bfd_bread ((PTR) lnsizedata, sizeof (lnsizedata), abfd)
+	   != sizeof (lnsizedata)))
 	{
 	  error ("can't read DWARF line number table size");
 	}
@@ -2294,7 +2294,7 @@ read_ofile_symtab (struct partial_symtab
 			       GET_UNSIGNED, pst->objfile);
       lnbase = xmalloc (lnsize);
       if (bfd_seek (abfd, LNFOFF (pst), SEEK_SET) ||
-	  (bfd_read (lnbase, lnsize, 1, abfd) != lnsize))
+	  (bfd_bread (lnbase, lnsize, abfd) != lnsize))
 	{
 	  xfree (lnbase);
 	  error ("can't read DWARF line numbers");
Index: somread.c
===================================================================
RCS file: /cvs/src/src/gdb/somread.c,v
retrieving revision 1.10
diff -u -p -r1.10 somread.c
--- somread.c	2001/03/06 08:21:17	1.10
+++ somread.c	2001/09/18 10:23:02
@@ -101,13 +101,13 @@ som_symtab_read (bfd *abfd, struct objfi
 
   buf = alloca (symsize * number_of_symbols);
   bfd_seek (abfd, obj_som_sym_filepos (abfd), SEEK_SET);
-  val = bfd_read (buf, symsize * number_of_symbols, 1, abfd);
+  val = bfd_bread (buf, symsize * number_of_symbols, abfd);
   if (val != symsize * number_of_symbols)
     error ("Couldn't read symbol dictionary!");
 
   stringtab = alloca (obj_som_stringtab_size (abfd));
   bfd_seek (abfd, obj_som_str_filepos (abfd), SEEK_SET);
-  val = bfd_read (stringtab, obj_som_stringtab_size (abfd), 1, abfd);
+  val = bfd_bread (stringtab, obj_som_stringtab_size (abfd), abfd);
   if (val != obj_som_stringtab_size (abfd))
     error ("Can't read in HP string table.");
 
Index: ultra3-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/ultra3-nat.c,v
retrieving revision 1.8
diff -u -p -r1.8 ultra3-nat.c
--- ultra3-nat.c	2001/05/04 04:15:28	1.8
+++ ultra3-nat.c	2001/09/18 10:23:02
@@ -273,7 +273,7 @@
 /* OBSOLETE       if (!CANNOT_FETCH_REGISTER (regno)) */
 /* OBSOLETE 	{ */
 /* OBSOLETE 	  val = bfd_seek (core_bfd, (file_ptr) register_addr (regno, 0), SEEK_SET); */
-/* OBSOLETE 	  if (val < 0 || (val = bfd_read (buf, sizeof buf, 1, core_bfd)) < 0) */
+/* OBSOLETE 	  if (val != 0 || (val = bfd_bread (buf, sizeof buf, core_bfd)) != sizeof buf) */
 /* OBSOLETE 	    { */
 /* OBSOLETE 	      char *buffer = (char *) alloca (strlen (REGISTER_NAME (regno)) + 35); */
 /* OBSOLETE 	      strcpy (buffer, "Reading core register "); */
Index: xcoffread.c
===================================================================
RCS file: /cvs/src/src/gdb/xcoffread.c,v
retrieving revision 1.15
diff -u -p -r1.15 xcoffread.c
--- xcoffread.c	2001/09/05 02:13:11	1.15
+++ xcoffread.c	2001/09/18 10:23:04
@@ -817,7 +817,7 @@ enter_line_range (struct subfile *subfil
   while (curoffset <= limit_offset)
     {
       bfd_seek (abfd, curoffset, SEEK_SET);
-      bfd_read (ext_lnno, linesz, 1, abfd);
+      bfd_bread (ext_lnno, linesz, abfd);
       bfd_coff_swap_lineno_in (abfd, ext_lnno, &int_lnno);
 
       /* Find the address this line represents.  */
@@ -1923,7 +1923,7 @@ init_stringtab (bfd *abfd, file_ptr offs
     error ("cannot seek to string table in %s: %s",
 	   bfd_get_filename (abfd), bfd_errmsg (bfd_get_error ()));
 
-  val = bfd_read ((char *) lengthbuf, 1, sizeof lengthbuf, abfd);
+  val = bfd_bread ((char *) lengthbuf, sizeof lengthbuf, abfd);
   length = bfd_h_get_32 (abfd, lengthbuf);
 
   /* If no string table is needed, then the file may end immediately
@@ -1944,8 +1944,7 @@ init_stringtab (bfd *abfd, file_ptr offs
   if (length == sizeof lengthbuf)
     return;
 
-  val = bfd_read (strtbl + sizeof lengthbuf, 1, length - sizeof lengthbuf,
-		  abfd);
+  val = bfd_bread (strtbl + sizeof lengthbuf, length - sizeof lengthbuf, abfd);
 
   if (val != length - sizeof lengthbuf)
     error ("cannot read string table from %s: %s",
@@ -2677,8 +2676,8 @@ xcoff_initial_scan (struct objfile *objf
   ((struct coff_symfile_info *) objfile->sym_private)->symtbl_num_syms =
     num_symbols;
 
-  val = bfd_read (((struct coff_symfile_info *) objfile->sym_private)->symtbl,
-		  size, 1, abfd);
+  val = bfd_bread (((struct coff_symfile_info *) objfile->sym_private)->symtbl,
+		   size, abfd);
   if (val != size)
     perror_with_name ("reading symbol table");
 

Re: bfd_read and bfd_write

[Andrew Cagney]

> On Thu, Sep 06, 2001 at 06:32:13PM +0100, Nick Clifton wrote:
> 
>> I like the idea of adding the new interface, with new function names,
>> and a warning message being generated if the old interface is used, as
>> part of the current CVS sources/forthcoming release.  Then in the
>> release after that, we can remove the old interface.
> 
> 
> Here is the patch to gdb/ to move over to the new bfd_bread and bfd_bwrite
> functions, which have just been committed.
> 
> 	* coffread.c: Replace all occurrences of bfd_read with bfd_bread.
> 	* dbxread.c: Likewise.
> 	* dwarf2read.c: Likewise.
> 	* dwarfread.c: Likewise.
> 	* somread.c: Likewise.
> 	* ultra3-nat.c: Likewise.
> 	* xcoffread.c: Likewise.
> 
> OK to apply?


yep.

Andrew

Re: bfd_read and bfd_write

[Andrew Cagney]

Alan, just a PS.  Can you please check to see if you have a GDB 
assignment in place(1).  With that you're free to add yourself to GDB's 
write after approval list.

enjoy,
Andrew

(1) I couldn't find one.  Your mechanical change doesn't need an assignment.