Use bfd_get_filename throughout gdb

Use bfd_get_filename throughout gdb

[Alan Modra]

ref: https://sourceware.org/pipermail/binutils/2020-May/111154.html

This patch makes gdb use the inline accessor for all bfd->filename
read accesses.

OK to apply after the 9.2 release happens?

	* coff-pe-read.c (read_pe_exported_syms): Use bfd_get_filename
	rather than accessing bfd->filename directly.
	* dtrace-probe.c (dtrace_static_probe_ops::get_probes): Likewise,
	and use bfd_section_name.
	* dwarf2/frame.c (decode_frame_entry): Likewise.
	* exec.c (exec_set_section_address): Likewise.
	* solib-aix.c (solib_aix_bfd_open): Likewise.
	* stap-probe.c (get_stap_base_address): Likewise.
	* symfile.c (reread_symbols): Likewise.

diff --git a/gdb/coff-pe-read.c b/gdb/coff-pe-read.c
index 3ecfb3d061..9253cb115f 100644
--- a/gdb/coff-pe-read.c
+++ b/gdb/coff-pe-read.c
@@ -342,7 +342,7 @@ read_pe_exported_syms (minimal_symbol_reader &reader,
   unsigned long exp_funcbase;
   unsigned char *expdata, *erva;
   unsigned long name_rvas, ordinals, nexp, ordbase;
-  char *dll_name = (char *) dll->filename;
+  char *dll_name = (char *) bfd_get_filename (dll);
   int otherix = PE_SECTION_TABLE_SIZE;
   int is_pe64 = 0;
   int is_pe32 = 0;
diff --git a/gdb/dtrace-probe.c b/gdb/dtrace-probe.c
index c452ac9b47..ce96037be2 100644
--- a/gdb/dtrace-probe.c
+++ b/gdb/dtrace-probe.c
@@ -860,7 +860,7 @@ dtrace_static_probe_ops::get_probes
          else
 	    complaint (_("could not obtain the contents of"
 			 "section '%s' in objfile `%s'."),
-		       sect->name, abfd->filename);
+		       bfd_section_name (sect), bfd_get_filename (abfd));
 
 	  xfree (dof);
 	}
diff --git a/gdb/dwarf2/frame.c b/gdb/dwarf2/frame.c
index f7276d48ce..a05f841817 100644
--- a/gdb/dwarf2/frame.c
+++ b/gdb/dwarf2/frame.c
@@ -2101,21 +2101,21 @@ decode_frame_entry (struct gdbarch *gdbarch,
     case ALIGN4:
       complaint (_("\
 Corrupt data in %s:%s; align 4 workaround apparently succeeded"),
-		 unit->dwarf_frame_section->owner->filename,
-		 unit->dwarf_frame_section->name);
+		 bfd_get_filename (unit->dwarf_frame_section->owner),
+		 bfd_section_name (unit->dwarf_frame_section));
       break;
 
     case ALIGN8:
       complaint (_("\
 Corrupt data in %s:%s; align 8 workaround apparently succeeded"),
-		 unit->dwarf_frame_section->owner->filename,
-		 unit->dwarf_frame_section->name);
+		 bfd_get_filename (unit->dwarf_frame_section->owner),
+		 bfd_section_name (unit->dwarf_frame_section));
       break;
 
     default:
       complaint (_("Corrupt data in %s:%s"),
-		 unit->dwarf_frame_section->owner->filename,
-		 unit->dwarf_frame_section->name);
+		 bfd_get_filename (unit->dwarf_frame_section->owner),
+		 bfd_section_name (unit->dwarf_frame_section));
       break;
     }
 
diff --git a/gdb/exec.c b/gdb/exec.c
index a2added5e2..a561a17022 100644
--- a/gdb/exec.c
+++ b/gdb/exec.c
@@ -1138,7 +1138,8 @@ exec_set_section_address (const char *filename, int index, CORE_ADDR address)
   table = current_target_sections;
   for (p = table->sections; p < table->sections_end; p++)
     {
-      if (filename_cmp (filename, p->the_bfd_section->owner->filename) == 0
+      if (filename_cmp (filename,
+			bfd_get_filename (p->the_bfd_section->owner)) == 0
 	  && index == p->the_bfd_section->index)
 	{
 	  p->endaddr += address - p->addr;
diff --git a/gdb/solib-aix.c b/gdb/solib-aix.c
index 125c8960c2..5da1214a25 100644
--- a/gdb/solib-aix.c
+++ b/gdb/solib-aix.c
@@ -611,7 +611,7 @@ solib_aix_bfd_open (const char *pathname)
     (gdb_bfd_openr_next_archived_file (archive_bfd.get (), NULL));
   while (object_bfd != NULL)
     {
-      if (member_name == object_bfd->filename)
+      if (member_name == bfd_get_filename (object_bfd.get ()))
 	break;
 
       object_bfd = gdb_bfd_openr_next_archived_file (archive_bfd.get (),
diff --git a/gdb/stap-probe.c b/gdb/stap-probe.c
index 4b1a75f816..73596446cc 100644
--- a/gdb/stap-probe.c
+++ b/gdb/stap-probe.c
@@ -1606,7 +1606,7 @@ get_stap_base_address (bfd *obfd, bfd_vma *base)
     {
       complaint (_("could not obtain base address for "
 					"SystemTap section on objfile `%s'."),
-		 obfd->filename);
+		 bfd_get_filename (obfd));
       return 0;
     }
 
diff --git a/gdb/symfile.c b/gdb/symfile.c
index 946443f07a..45663b594b 100644
--- a/gdb/symfile.c
+++ b/gdb/symfile.c
@@ -2453,7 +2453,7 @@ reread_symbols (void)
 	 a `shared library' on AIX is also an archive), then you should
 	 stat on the archive name, not member name.  */
       if (objfile->obfd->my_archive)
-	res = stat (objfile->obfd->my_archive->filename, &new_statbuf);
+	res = stat (bfd_get_filename (objfile->obfd->my_archive), &new_statbuf);
       else
 	res = stat (objfile_name (objfile), &new_statbuf);
       if (res != 0)

-- 
Alan Modra
Australia Development Lab, IBM

Re: Use bfd_get_filename throughout gdb

[Simon Marchi]

On 2020-05-19 12:12 a.m., Alan Modra via Gdb-patches wrote:
> ref: https://sourceware.org/pipermail/binutils/2020-May/111154.html
> 
> This patch makes gdb use the inline accessor for all bfd->filename
> read accesses.
> 
> OK to apply after the 9.2 release happens?

Hi Alan,

This is ok to push to the master branch.  The 9.2 release happens from the gdb-9-branch
anyway.

This doesn't prevent new code from using the field (in some of my pending patches,
I'm pretty sure I have some code that accesses it).  Short of being able to make the
field private, have you thought of leaving the field's name changed?  Perhaps adopting
a naming convention that says "this field is private" and adding a comment above it to
say "don't access this directly, use bfd_get_filename"?

Simon

Re: Use bfd_get_filename throughout gdb

[Alan Modra]

On Tue, May 19, 2020 at 09:10:29AM -0400, Simon Marchi wrote:
> On 2020-05-19 12:12 a.m., Alan Modra via Gdb-patches wrote:
> > ref: https://sourceware.org/pipermail/binutils/2020-May/111154.html
> > 
> > This patch makes gdb use the inline accessor for all bfd->filename
> > read accesses.
> > 
> > OK to apply after the 9.2 release happens?
> 
> Hi Alan,
> 
> This is ok to push to the master branch.  The 9.2 release happens from the gdb-9-branch
> anyway.

I guess I should have noticed that.  Now pushed.

> This doesn't prevent new code from using the field (in some of my pending patches,
> I'm pretty sure I have some code that accesses it).  Short of being able to make the
> field private, have you thought of leaving the field's name changed?  Perhaps adopting
> a naming convention that says "this field is private" and adding a comment above it to
> say "don't access this directly, use bfd_get_filename"?

Yes, I did think of leaving the field as "xfilename".  I put if back
to "filename" thinking I may have missed some places (files not
compiled or conditional compilation), and out of consideration for
out-of-tree projects like oprofile.

Also, there are quite a few other fields of struct bfd and struct
bfd_section that should be "made private".  A wholesale field renaming
change is probably better.

-- 
Alan Modra
Australia Development Lab, IBM