add-symbol-file-from-memory patch breaks non-elf targets?

add-symbol-file-from-memory patch breaks non-elf targets?

[Randolph Chung]

Roland, this patch:

http://sources.redhat.com/ml/gdb-patches/2004-04/msg00330.html

seems to have broken the hppa2.0w-hp-hpux11.11 build. This target does 
not use ELF, so bfd isn't built with elf.lo and 
bfd_elf_bfd_from_remote_memory is not available.

can we do this without an elf dependency?

thanks,
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: add-symbol-file-from-memory patch breaks non-elf targets?

[Roland McGrath]

When this was all discussed originally (deciding the bfd interface), people
didn't seem concerned about non-ELF targets and seemed to prefer avoiding a
adding a bfd target function rather than just an ELF-specific interface.
Unless bfd maintainers change their minds, that's what we have for the bfd
interface--so callers of it are inherently ELF-specific.  

In gdb, I could not find, and still cannot find, a reasonable way to
conditionalize something at compile time on "will there be ELF".  Hence the
runtime check for bfd_target_elf_flavour, and the unconditional link-time
reference to bfd_elf_bfd_from_remote_memory.  AFAICT, elfread.c is always
built into gdb even for non-ELF targets, as a further example telling me
there really is no good way to conditionalize this correctly.  It happens
not to use any bfd_elf_* interfaces and so links ok and is just dead code
in ELFless configurations.  

I am open to suggestions.


Thanks,
Roland

Re: add-symbol-file-from-memory patch breaks non-elf targets?

[Randolph Chung]

> In gdb, I could not find, and still cannot find, a reasonable way to
> conditionalize something at compile time on "will there be ELF".  

can we add an autoconf check for this?

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: add-symbol-file-from-memory patch breaks non-elf targets?

[Roland McGrath]

> > In gdb, I could not find, and still cannot find, a reasonable way to
> > conditionalize something at compile time on "will there be ELF".  
> 
> can we add an autoconf check for this?

I had that thought, but I am really not sure off hand if it will work right.
That is, gdb/configure needs to do a check by linking against libbfd.
libbfd is built in the same tree, not installed on the system.

Re: add-symbol-file-from-memory patch breaks non-elf targets?

[Andrew Cagney]

>>In gdb, I could not find, and still cannot find, a reasonable way to
>>> conditionalize something at compile time on "will there be ELF".  
> 
> 
> can we add an autoconf check for this?

That shouldn't be necessary.

Andrew

Re: add-symbol-file-from-memory patch breaks non-elf targets?

[Joel Brobecker]

> >can we add an autoconf check for this?
> 
> That shouldn't be necessary.

So the real problem, according to you, is that elf.c is not compiled in
libbfd.a, is that right? I think it is important we fix this breakage
asap because all our non-elf targets are broken at the moment, so I
might jump in tomorrow and have a look (I have something else pretty
important to do tomorrow beforehand, but I'll make some time for it)

-- 
Joel

Re: add-symbol-file-from-memory patch breaks non-elf targets?

[Jim Blandy]

Roland McGrath <roland@redhat.com> writes:
> In gdb, I could not find, and still cannot find, a reasonable way to
> conditionalize something at compile time on "will there be ELF".  Hence the
> runtime check for bfd_target_elf_flavour, and the unconditional link-time
> reference to bfd_elf_bfd_from_remote_memory.  AFAICT, elfread.c is always
> built into gdb even for non-ELF targets, as a further example telling me
> there really is no good way to conditionalize this correctly.  It happens
> not to use any bfd_elf_* interfaces and so links ok and is just dead code
> in ELFless configurations.  
> 
> I am open to suggestions.

I remember this coming up now; I wish I had remembered it before I
approved the patch.

I messed around with it, and I couldn't find a good place either.  How
about creating a new file, elf-tdep.c, putting the code there, and
having linux.mt add elf-tdep.o to the link?

Re: add-symbol-file-from-memory patch breaks non-elf targets?

[Andrew Cagney]

> I messed around with it, and I couldn't find a good place either.  How
> about creating a new file, elf-tdep.c, putting the code there, and
> having linux.mt add elf-tdep.o to the link?

It really isn't OSABI specific so *-tdep.c would be wrong (-tdep is a 
misleading suffix).  Something like solib-mem.c comes to mind but that 
is still a hack.

Andrew

Re: add-symbol-file-from-memory patch breaks non-elf targets?

[Jim Blandy]

All right, here's a patch, tested on i686-pc-linux-gnu,
powerpc-unknown-linux-gnu, and powerpc-ibm-aix4.3.3.0.  Could folks
try it out?

2004-04-22  Jim Blandy  <jimb@redhat.com>

	Move the symbol-file-from-memory functions into their own file.
	* symfile-mem.c, symfile-mem.h: New files.
	* symfile.c (symbol_file_add_from_bfd): New function.
	(symbol_file_add): Call symbol_file_add_from_bfd.
	(symbol_file_add_from_memory, add_symbol_file_from_memory_command):
	Moved to symfile-mem.c.
	(_initialize_symfile): Move definition of
	add-symbol-file-from-memory command to symfile-mem.c.
	* symfile.h (symbol_file_add_from_bfd): New declaration.
	* config/i386/linux.mt (TDEPFILES): Add symfile-mem.o.
 	* config/powerpc/linux.mt (TDEPFILES): Same.
	* Makefile.in (SFILES): Add symfile-mem.c.
	(symfile_mem_h): New variable.
	(HFILES_NO_SRCDIR): Add symfile-mem.h.
	(symfile-mem.o): New rule.

Index: gdb/Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.548
diff -c -r1.548 Makefile.in
*** gdb/Makefile.in	22 Apr 2004 21:13:06 -0000	1.548
--- gdb/Makefile.in	23 Apr 2004 02:03:57 -0000
***************
*** 538,544 ****
  	scm-exp.c scm-lang.c scm-valprint.c \
  	sentinel-frame.c \
  	serial.c ser-unix.c source.c \
! 	stabsread.c stack.c std-regs.c symfile.c symmisc.c symtab.c \
  	target.c thread.c top.c tracepoint.c \
  	trad-frame.c \
  	tramp-frame.c \
--- 538,545 ----
  	scm-exp.c scm-lang.c scm-valprint.c \
  	sentinel-frame.c \
  	serial.c ser-unix.c source.c \
! 	stabsread.c stack.c std-regs.c symfile.c symfile-mem.c symmisc.c \
! 	symtab.c \
  	target.c thread.c top.c tracepoint.c \
  	trad-frame.c \
  	tramp-frame.c \
***************
*** 754,759 ****
--- 755,761 ----
  stabsread_h = stabsread.h
  stack_h = stack.h
  symfile_h = symfile.h
+ symfile_mem_h = symfile-mem.h
  symtab_h = symtab.h
  target_h = target.h $(bfd_h) $(symtab_h) $(dcache_h) $(memattr_h)
  terminal_h = terminal.h
***************
*** 828,834 ****
  	environ.h $(gdbcmd_h) gdb.h gdbcore.h \
  	gdb-stabs.h $(inferior_h) language.h minimon.h monitor.h \
  	objfiles.h parser-defs.h serial.h solib.h \
! 	symfile.h stabsread.h target.h terminal.h typeprint.h xcoffsolib.h \
  	macrotab.h macroexp.h macroscope.h \
  	c-lang.h f-lang.h \
  	jv-lang.h \
--- 830,837 ----
  	environ.h $(gdbcmd_h) gdb.h gdbcore.h \
  	gdb-stabs.h $(inferior_h) language.h minimon.h monitor.h \
  	objfiles.h parser-defs.h serial.h solib.h \
! 	symfile.h symfile-mem.h stabsread.h target.h terminal.h typeprint.h \
! 	xcoffsolib.h \
  	macrotab.h macroexp.h macroscope.h \
  	c-lang.h f-lang.h \
  	jv-lang.h \
***************
*** 2429,2434 ****
--- 2432,2440 ----
  	$(gdb_stabs_h) $(gdb_obstack_h) $(completer_h) $(bcache_h) \
  	$(hashtab_h) $(readline_h) $(gdb_assert_h) $(block_h) \
  	$(gdb_string_h) $(gdb_stat_h)
+ symfile-mem.o: symfile-mem.c $(defs_h) $(symtab_h) $(gdbcore_h) \
+ 	$(objfiles_h) $(gdbcmd_h) $(target_h) $(value_h) $(symfile_h) \
+ 	$(symfile_mem_h)
  symmisc.o: symmisc.c $(defs_h) $(symtab_h) $(gdbtypes_h) $(bfd_h) \
  	$(symfile_h) $(objfiles_h) $(breakpoint_h) $(command_h) \
  	$(gdb_obstack_h) $(language_h) $(bcache_h) $(block_h) $(gdb_regex_h) \
Index: gdb/symfile-mem.c
===================================================================
RCS file: gdb/symfile-mem.c
diff -N gdb/symfile-mem.c
*** gdb/symfile-mem.c	1 Jan 1970 00:00:00 -0000
--- gdb/symfile-mem.c	23 Apr 2004 02:03:58 -0000
***************
*** 0 ****
--- 1,151 ----
+ /* Reading symbol files from memory.
+ 
+    Copyright 1986, 1987, 1989, 1991, 1994, 1995, 1996, 1998, 2000,
+    2001, 2002, 2003, 2004 Free Software Foundation, Inc.
+ 
+    This file is part of GDB.
+ 
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+ 
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+ 
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 59 Temple Place - Suite 330,
+    Boston, MA 02111-1307, USA.  */
+ 
+ /* This file defines functions (and commands to exercise those
+    functions) for reading debugging information from object files
+    whose images are mapped directly into the inferior's memory.  For
+    example, the Linux kernel maps a "syscall DSO" into each process's
+    address space; this DSO provides kernel-specific code for some
+    system calls.
+ 
+    At the moment, BFD only has functions for parsing object files from
+    memory for the ELF format, even though the general idea isn't
+    ELF-specific.  This means that BFD only provides the functions GDB
+    needs when configured for ELF-based targets.  So these functions
+    may only be compiled on ELF-based targets.
+ 
+    GDB has no idea whether it has been configured for an ELF-based
+    target or not: it just tries to handle whatever files it is given.
+    But this means there are no preprocessor symbols on which we could
+    make these functions' compilation conditional.
+ 
+    So, for the time being, we put these functions alone in this file,
+    and have .mt files reference them as appropriate.  In the future, I
+    hope BFD will provide a format-independent bfd_from_remote_memory
+    entry point.  */
+ 
+ 
+ #include "defs.h"
+ #include "symtab.h"
+ #include "gdbcore.h"
+ #include "objfiles.h"
+ #include "gdbcmd.h"
+ #include "target.h"
+ #include "value.h"
+ #include "symfile.h"
+ #include "symfile-mem.h"
+ 
+ 
+ /* Read inferior memory at ADDR to find the header of a loaded object file
+    and read its in-core symbols out of inferior memory.  TEMPL is a bfd
+    representing the target's format.  */
+ struct objfile *
+ symbol_file_add_from_memory (bfd *templ, CORE_ADDR addr, int from_tty)
+ {
+   struct objfile *objf;
+   bfd *nbfd;
+   asection *sec;
+   bfd_vma loadbase;
+   struct section_addr_info *sai;
+   unsigned int i;
+ 
+   if (bfd_get_flavour (templ) != bfd_target_elf_flavour)
+     error ("add-symbol-file-from-memory not supported for this target");
+ 
+   nbfd = bfd_elf_bfd_from_remote_memory (templ, addr, &loadbase,
+ 					 target_read_memory);
+   if (nbfd == NULL)
+     {
+       error ("Failed to read a valid object file image from memory.");
+       return NULL;
+     }
+ 
+   nbfd->filename = xstrdup ("shared object read from target memory");
+ 
+   if (!bfd_check_format (nbfd, bfd_object))
+     {
+       /* FIXME: should be checking for errors from bfd_close (for one thing,
+          on error it does not free all the storage associated with the
+          bfd).  */
+       bfd_close (nbfd);
+       error ("Got object file from memory but can't read symbols: %s.",
+ 	     bfd_errmsg (bfd_get_error ()));
+       return NULL;
+     }
+ 
+   sai = alloc_section_addr_info (bfd_count_sections (nbfd));
+   make_cleanup (xfree, sai);
+   i = 0;
+   for (sec = nbfd->sections; sec != NULL; sec = sec->next)
+     if ((bfd_get_section_flags (nbfd, sec) & (SEC_ALLOC|SEC_LOAD)) != 0)
+       {
+ 	sai->other[i].addr = bfd_get_section_vma (nbfd, sec) + loadbase;
+ 	sai->other[i].name = (char *) bfd_get_section_name (nbfd, sec);
+ 	sai->other[i].sectindex = sec->index;
+ 	++i;
+       }
+ 
+   objf = symbol_file_add_from_bfd (nbfd, from_tty,
+                                    sai, 0, OBJF_SHARED);
+ 
+   /* This might change our ideas about frames already looked at.  */
+   reinit_frame_cache ();
+ 
+   return objf;
+ }
+ 
+ 
+ static void
+ add_symbol_file_from_memory_command (char *args, int from_tty)
+ {
+   CORE_ADDR addr;
+   bfd *templ;
+ 
+   if (args == NULL)
+     error ("add-symbol-file-from-memory requires an expression argument");
+ 
+   addr = parse_and_eval_address (args);
+ 
+   /* We need some representative bfd to know the target we are looking at.  */
+   if (symfile_objfile != NULL)
+     templ = symfile_objfile->obfd;
+   else
+     templ = exec_bfd;
+   if (templ == NULL)
+     error ("\
+ Must use symbol-file or exec-file before add-symbol-file-from-memory.");
+ 
+   symbol_file_add_from_memory (templ, addr, from_tty);
+ }
+ 
+ \f
+ void
+ _initialize_symfile_mem ()
+ {
+   add_cmd ("add-symbol-file-from-memory", class_files,
+            add_symbol_file_from_memory_command,
+            "\
+ Load the symbols out of memory from a dynamically loaded object file.\n\
+ Give an expression for the address of the file's shared object file header.",
+            &cmdlist);
+ 
+ }
Index: gdb/symfile-mem.h
===================================================================
RCS file: gdb/symfile-mem.h
diff -N gdb/symfile-mem.h
*** gdb/symfile-mem.h	1 Jan 1970 00:00:00 -0000
--- gdb/symfile-mem.h	23 Apr 2004 02:03:58 -0000
***************
*** 0 ****
--- 1,33 ----
+ /* Declarations for reading symbol files from memory into GDB.
+ 
+    Copyright 2004 Free Software Foundation, Inc.
+ 
+    This file is part of GDB.
+ 
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+ 
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+ 
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 59 Temple Place - Suite 330,
+    Boston, MA 02111-1307, USA.  */
+ 
+ #if !defined (SYMFILE_MEM_H)
+ #define SYMFILE_MEM_H
+ 
+ /* You must #include "bfd.h" and "defs.h" before #including this file.  */
+ 
+ /* Forward declarations.  */
+ struct objfile;
+ 
+ struct objfile *(symbol_file_add_from_memory
+                  (bfd *templ, CORE_ADDR addr, int from_tty));
+ 
+ #endif /* SYMFILE_MEM_H */
Index: gdb/symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.128
diff -c -r1.128 symfile.c
*** gdb/symfile.c	21 Apr 2004 23:52:21 -0000	1.128
--- gdb/symfile.c	23 Apr 2004 02:04:00 -0000
***************
*** 910,915 ****
--- 910,931 ----
  }
  
  
+ /* Process the symbol file ABFD, as either the main file or as a
+    dynamically loaded file.
+ 
+    See symbol_file_add_with_addrs_or_offsets's comments for
+    details.  */
+ struct objfile *
+ symbol_file_add_from_bfd (bfd *abfd, int from_tty,
+                           struct section_addr_info *addrs,
+                           int mainline, int flags)
+ {
+   return symbol_file_add_with_addrs_or_offsets (abfd,
+ 						from_tty, addrs, 0, 0,
+                                                 mainline, flags);
+ }
+ 
+ 
  /* Process a symbol file, as either the main file or as a dynamically
     loaded file.  See symbol_file_add_with_addrs_or_offsets's comments
     for details.  */
***************
*** 917,925 ****
  symbol_file_add (char *name, int from_tty, struct section_addr_info *addrs,
  		 int mainline, int flags)
  {
!   return symbol_file_add_with_addrs_or_offsets (symfile_bfd_open (name),
! 						from_tty, addrs, 0, 0,
!                                                 mainline, flags);
  }
  
  
--- 933,940 ----
  symbol_file_add (char *name, int from_tty, struct section_addr_info *addrs,
  		 int mainline, int flags)
  {
!   return symbol_file_add_from_bfd (symfile_bfd_open (name), from_tty,
!                                    addrs, mainline, flags);
  }
  
  
***************
*** 1769,1861 ****
  #endif
  }
  \f
- #if 0
- /* Read inferior memory at ADDR to find the header of a loaded object file
-    and read its in-core symbols out of inferior memory.  TEMPL is a bfd
-    representing the target's format.  */
- struct objfile *
- symbol_file_add_from_memory (bfd *templ, CORE_ADDR addr, int from_tty)
- {
-   struct objfile *objf;
-   bfd *nbfd;
-   asection *sec;
-   bfd_vma loadbase;
-   struct section_addr_info *sai;
-   unsigned int i;
- 
-   if (bfd_get_flavour (templ) != bfd_target_elf_flavour)
-     error ("add-symbol-file-from-memory not supported for this target");
- 
-   nbfd = bfd_elf_bfd_from_remote_memory (templ, addr, &loadbase,
- 					 target_read_memory);
-   if (nbfd == NULL)
-     {
-       error ("Failed to read a valid object file image from memory.");
-       return NULL;
-     }
- 
-   nbfd->filename = xstrdup ("shared object read from target memory");
- 
-   if (!bfd_check_format (nbfd, bfd_object))
-     {
-       /* FIXME: should be checking for errors from bfd_close (for one thing,
-          on error it does not free all the storage associated with the
-          bfd).  */
-       bfd_close (nbfd);
-       error ("Got object file from memory but can't read symbols: %s.",
- 	     bfd_errmsg (bfd_get_error ()));
-       return NULL;
-     }
- 
-   sai = alloc_section_addr_info (bfd_count_sections (nbfd));
-   make_cleanup (xfree, sai);
-   i = 0;
-   for (sec = nbfd->sections; sec != NULL; sec = sec->next)
-     if ((bfd_get_section_flags (nbfd, sec) & (SEC_ALLOC|SEC_LOAD)) != 0)
-       {
- 	sai->other[i].addr = bfd_get_section_vma (nbfd, sec) + loadbase;
- 	sai->other[i].name = (char *) bfd_get_section_name (nbfd, sec);
- 	sai->other[i].sectindex = sec->index;
- 	++i;
-       }
- 
-   objf = symbol_file_add_with_addrs_or_offsets (nbfd, from_tty,
- 						sai, NULL, 0, 0, OBJF_SHARED);
- 
-   /* This might change our ideas about frames already looked at.  */
-   reinit_frame_cache ();
- 
-   return objf;
- }
- #endif
- 
- static void
- add_symbol_file_from_memory_command (char *args, int from_tty)
- {
- #if 0
-   CORE_ADDR addr;
-   bfd *templ;
- 
-   if (args == NULL)
-     error ("add-symbol-file-from-memory requires an expression argument");
- 
-   addr = parse_and_eval_address (args);
- 
-   /* We need some representative bfd to know the target we are looking at.  */
-   if (symfile_objfile != NULL)
-     templ = symfile_objfile->obfd;
-   else
-     templ = exec_bfd;
-   if (templ == NULL)
-     error ("\
- Must use symbol-file or exec-file before add-symbol-file-from-memory.");
- 
-   symbol_file_add_from_memory (templ, addr, from_tty);
- #else
-   error ("add-symbol-file-from-memory not implemented");
- #endif
- }
- \f
  /* Re-read symbols if a symbol-file has changed.  */
  void
  reread_symbols (void)
--- 1784,1789 ----
***************
*** 3614,3626 ****
  with the text.  SECT is a section name to be loaded at SECT_ADDR.",
  	       &cmdlist);
    set_cmd_completer (c, filename_completer);
- 
-   c = add_cmd ("add-symbol-file-from-memory", class_files,
- 	       add_symbol_file_from_memory_command,
- 	       "\
- Load the symbols out of memory from a dynamically loaded object file.\n\
- Give an expression for the address of the file's shared object file header.",
- 	       &cmdlist);
  
    c = add_cmd ("add-shared-symbol-files", class_files,
  	       add_shared_symbol_files_command,
--- 3542,3547 ----
Index: gdb/symfile.h
===================================================================
RCS file: /cvs/src/src/gdb/symfile.h,v
retrieving revision 1.29
diff -c -r1.29 symfile.h
*** gdb/symfile.h	15 Apr 2004 21:39:27 -0000	1.29
--- gdb/symfile.h	23 Apr 2004 02:04:00 -0000
***************
*** 189,194 ****
--- 189,198 ----
  extern struct objfile *symbol_file_add (char *, int,
  					struct section_addr_info *, int, int);
  
+ extern struct objfile *symbol_file_add_from_bfd (bfd *, int,
+                                                  struct section_addr_info *,
+                                                  int, int);
+ 
  /* Create a new section_addr_info, with room for NUM_SECTIONS.  */
  
  extern struct section_addr_info *alloc_section_addr_info (size_t
Index: gdb/config/i386/linux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/linux.mt,v
retrieving revision 1.8
diff -c -r1.8 linux.mt
*** gdb/config/i386/linux.mt	9 Apr 2004 16:39:37 -0000	1.8
--- gdb/config/i386/linux.mt	23 Apr 2004 02:04:00 -0000
***************
*** 1,4 ****
  # Target: Intel 386 running GNU/Linux
  TDEPFILES= i386-tdep.o i386-linux-tdep.o glibc-tdep.o i387-tdep.o \
! 	solib.o solib-svr4.o
  TM_FILE= tm-linux.h
--- 1,4 ----
  # Target: Intel 386 running GNU/Linux
  TDEPFILES= i386-tdep.o i386-linux-tdep.o glibc-tdep.o i387-tdep.o \
! 	solib.o solib-svr4.o symfile-mem.o
  TM_FILE= tm-linux.h
Index: gdb/config/powerpc/linux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/powerpc/linux.mt,v
retrieving revision 1.6
diff -c -r1.6 linux.mt
*** gdb/config/powerpc/linux.mt	30 Jul 2002 19:03:49 -0000	1.6
--- gdb/config/powerpc/linux.mt	23 Apr 2004 02:04:01 -0000
***************
*** 1,6 ****
  # Target: Motorola PPC on Linux
  TDEPFILES= rs6000-tdep.o ppc-linux-tdep.o ppc-sysv-tdep.o solib.o \
! 	solib-svr4.o solib-legacy.o corelow.o
  TM_FILE= tm-linux.h
  
  SIM_OBS = remote-sim.o
--- 1,6 ----
  # Target: Motorola PPC on Linux
  TDEPFILES= rs6000-tdep.o ppc-linux-tdep.o ppc-sysv-tdep.o solib.o \
! 	solib-svr4.o solib-legacy.o symfile-mem.o corelow.o
  TM_FILE= tm-linux.h
  
  SIM_OBS = remote-sim.o

Re: add-symbol-file-from-memory patch breaks non-elf targets?

[Roland McGrath]

It's unfortunate that this is done in a way that requires a tweak for every
specific target.  The functionality will work, and thus ought to be
available, on any ELF target.  The use of symbol_file_add_from_memory from
other gdb code to support Linux's vDSO is already needed on more than one
Linux target and it is not unlikely that other Linux targets will follow
suit in the future.  It is crufty and makes maintenance error prone if we
have nothing better than copying and updating makefile boilerplate for
every specific Linux/CPU target.  For example, your patch covers only x86
and powerpc, but already IA64 and x86-64 need this support (and AFAIK not
yet powerpc).  

Re: add-symbol-file-from-memory patch breaks non-elf targets?

[Jim Blandy]

Roland McGrath <roland@redhat.com> writes:
> It's unfortunate that this is done in a way that requires a tweak for every
> specific target.  The functionality will work, and thus ought to be
> available, on any ELF target.  The use of symbol_file_add_from_memory from
> other gdb code to support Linux's vDSO is already needed on more than one
> Linux target and it is not unlikely that other Linux targets will follow
> suit in the future.  It is crufty and makes maintenance error prone if we
> have nothing better than copying and updating makefile boilerplate for
> every specific Linux/CPU target.  For example, your patch covers only x86
> and powerpc, but already IA64 and x86-64 need this support (and AFAIK not
> yet powerpc).  

But "any ELF target" is not a well-defined thing in GDB.  GDB just
tries to cope with whatever it gets.  GDB lets BFD keep track of what
object file formats are appropriate for what targets.

The reason I thought this approach would be appropriate is that it
resembles the way we handle the different dynamic linker debugging
protocols: each .mt file selects solib-mumble.o manually.  As far as I
know, this hasn't been much of a maintenance hassle.

Re: add-symbol-file-from-memory patch breaks non-elf targets?

[Joel Brobecker]

Jim,

> All right, here's a patch, tested on i686-pc-linux-gnu,
> powerpc-unknown-linux-gnu, and powerpc-ibm-aix4.3.3.0.  Could folks
> try it out?

I was able to build GDB on HPUX and tru64 with the patch applied.
I also ran the testsuite, and got results that were within the ballpark
figures I remember seeing for these targets. So it all looks good to me.

> 2004-04-22  Jim Blandy  <jimb@redhat.com>
> 
> 	Move the symbol-file-from-memory functions into their own file.
> 	* symfile-mem.c, symfile-mem.h: New files.
> 	* symfile.c (symbol_file_add_from_bfd): New function.
> 	(symbol_file_add): Call symbol_file_add_from_bfd.
> 	(symbol_file_add_from_memory, add_symbol_file_from_memory_command):
> 	Moved to symfile-mem.c.
> 	(_initialize_symfile): Move definition of
> 	add-symbol-file-from-memory command to symfile-mem.c.
> 	* symfile.h (symbol_file_add_from_bfd): New declaration.
> 	* config/i386/linux.mt (TDEPFILES): Add symfile-mem.o.
>  	* config/powerpc/linux.mt (TDEPFILES): Same.
> 	* Makefile.in (SFILES): Add symfile-mem.c.
> 	(symfile_mem_h): New variable.
> 	(HFILES_NO_SRCDIR): Add symfile-mem.h.
> 	(symfile-mem.o): New rule.

-- 
Joel

Re: add-symbol-file-from-memory patch breaks non-elf targets?

[Andrew Cagney]

> Roland McGrath <roland@redhat.com> writes:
> 
>>> It's unfortunate that this is done in a way that requires a tweak for every
>>> specific target.  The functionality will work, and thus ought to be
>>> available, on any ELF target.  The use of symbol_file_add_from_memory from
>>> other gdb code to support Linux's vDSO is already needed on more than one
>>> Linux target and it is not unlikely that other Linux targets will follow
>>> suit in the future.  It is crufty and makes maintenance error prone if we
>>> have nothing better than copying and updating makefile boilerplate for
>>> every specific Linux/CPU target.  For example, your patch covers only x86
>>> and powerpc, but already IA64 and x86-64 need this support (and AFAIK not
>>> yet powerpc).  
> 
> 
> But "any ELF target" is not a well-defined thing in GDB.  GDB just
> tries to cope with whatever it gets.  GDB lets BFD keep track of what
> object file formats are appropriate for what targets.
> 
> The reason I thought this approach would be appropriate is that it
> resembles the way we handle the different dynamic linker debugging
> protocols: each .mt file selects solib-mumble.o manually.  As far as I
> know, this hasn't been much of a maintenance hassle.

No, that's also a bug.  As part of multi-arch, GDB should be able to 
include multiple shlib mechanisms.

Anyway, looks like I'm fixing this.

Andrew