* [PATCH] add-symbol-file-from-memory command
@ 2003-05-20 7:01 Roland McGrath
0 siblings, 0 replies; 40+ messages in thread
From: Roland McGrath @ 2003-05-20 7:01 UTC (permalink / raw)
To: gdb-patches
This patch relies on the BFD patch I posted earlier adding the function
bfd_elf_bfd_from_remote_memory. This adds a user command
add-symbol-file-from-memory, which is like add-symbol-file but takes just
the address of an ELF header in inferior memory (and no other args) instead
of a file name.
This command may not really be worth having, but it serves to exercise the
underlying function symbol_file_add_from_memory. That function does the
work of reading symbols and unwind info from the Linux vsyscall DSO.
So please examine that new code.
This makes symfile.c call bfd_elf_bfd_from_remote_memory, which is
implemented in bfd/elf.c and so won't exist if there is no ELF target
backend configured into libbfd. I couldn't see any obvious place in gdb
that is conditionalized at compile-time on ELF; unless I'm missing
something elfread.c is always built in regardless of the presence of ELF
targets. Should I not be using this function in this file?
Thanks,
Roland
2003-05-19 Roland McGrath <roland@redhat.com>
* symfile.c (symbol_file_add_with_addrs_or_offsets): Take ABFD as
a new argument. Call symfile_bfd_open only if passed a null pointer.
(symbol_file_add, reread_separate_symbols): Update callers.
(build_addr_info): New function, helper for ...
(symbol_file_add_from_memory): New function.
(add_symbol_file_from_memory_command): New function using that.
(_initialize_symfile): Register it for add-symbol-file-from-memory.
* symfile.h (symbol_file_add_from_memory): Declare it.
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.93.6.1
diff -B -p -u -r1.93.6.1 symfile.c
--- symfile.c 18 May 2003 09:44:22 -0000 1.93.6.1
+++ symfile.c 20 May 2003 00:13:39 -0000
@@ -834,6 +834,10 @@ new_symfile_objfile (struct objfile *obj
NAME is the file name (which will be tilde-expanded and made
absolute herein) (but we don't free or modify NAME itself).
+ If ABFD is not null, it's already open and should be used instead of
+ opening the file by name. This BFD will be closed on error, and
+ is always consumed by this function.
+
FROM_TTY says how verbose to be.
MAINLINE specifies whether this is the main symbol file, or whether
@@ -846,7 +850,7 @@ new_symfile_objfile (struct objfile *obj
Upon success, returns a pointer to the objfile that was added.
Upon failure, jumps back to command level (never returns). */
static struct objfile *
-symbol_file_add_with_addrs_or_offsets (char *name, int from_tty,
+symbol_file_add_with_addrs_or_offsets (char *name, bfd *abfd, int from_tty,
struct section_addr_info *addrs,
struct section_offsets *offsets,
int num_offsets,
@@ -855,16 +859,19 @@ symbol_file_add_with_addrs_or_offsets (c
struct objfile *objfile;
struct partial_symtab *psymtab;
char *debugfile;
- bfd *abfd;
struct section_addr_info orig_addrs;
-
+ struct cleanup *old_chain;
+
if (addrs)
orig_addrs = *addrs;
/* Open a bfd for the file, and give user a chance to burp if we'd be
interactively wiping out any existing symbols. */
- abfd = symfile_bfd_open (name);
+ if (abfd == NULL)
+ abfd = symfile_bfd_open (name);
+
+ old_chain = make_cleanup_bfd_close (abfd);
if ((have_full_symbols () || have_partial_symbols ())
&& mainline
@@ -873,6 +880,7 @@ symbol_file_add_with_addrs_or_offsets (c
error ("Not confirmed.");
objfile = allocate_objfile (abfd, flags);
+ discard_cleanups (old_chain);
/* If the objfile uses a mapped symbol file, and we have a psymtab for
it, then skip reading any symbols at this time. */
@@ -998,7 +1006,8 @@ struct objfile *
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 (name, from_tty, addrs, 0, 0,
+ return symbol_file_add_with_addrs_or_offsets (name, NULL, from_tty,
+ addrs, 0, 0,
mainline, flags);
}
@@ -1848,6 +1857,102 @@ add_shared_symbol_files_command (char *a
#endif
}
\f
+/* Helper function passed to bfd_map_over_sections. */
+static void
+build_addr_info (bfd *abfd, asection *sectp, void *info)
+{
+ struct section_addr_info *const sai = info;
+ unsigned int i = 0;
+
+ if ((bfd_get_section_flags (abfd, sectp) & (SEC_ALLOC|SEC_LOAD)) == 0)
+ return;
+
+ while (sai->other[i++].name != NULL)
+ if (i == MAX_SECTIONS)
+ return;
+
+ sai->other[i].addr = bfd_get_section_vma (abfd, sectp);
+ sai->other[i].name = (char *) bfd_get_section_name (abfd, sectp);
+ sai->other[i].sectindex = sectp->index;
+}
+
+/* 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;
+ bfd_vma loadbase;
+ struct section_addr_info sai;
+ unsigned int i;
+
+ if (from_tty)
+ {
+ if (bfd_get_flavour (templ) != bfd_target_elf_flavour)
+ error ("add-symbol-file-from-memory not supported for this target");
+ }
+ else
+ gdb_assert (bfd_get_flavour (templ) == bfd_target_elf_flavour);
+
+ nbfd = bfd_elf_bfd_from_remote_memory (templ, addr, &loadbase,
+ target_read_memory);
+ if (nbfd == NULL)
+ {
+ if (from_tty)
+ error ("Failed to read a valid object file image from memory.");
+ return NULL;
+ }
+
+ 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);
+ if (from_tty)
+ error ("Got object file from memory but can't read symbols: %s.",
+ bfd_errmsg (bfd_get_error ()));
+ return NULL;
+ }
+
+ memset (&sai, 0, sizeof sai);
+ bfd_map_over_sections (nbfd, build_addr_info, &sai);
+ for (i = 0; i < MAX_SECTIONS && sai.other[i].name != NULL; ++i)
+ sai.other[i].addr += loadbase;
+
+ objf = symbol_file_add_with_addrs_or_offsets ("<in-memory>", nbfd, from_tty,
+ &sai, NULL, 0, 0, 0);
+
+ 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.");
+
+ (void) symbol_file_add_from_memory (templ, addr, from_tty);
+}
+\f
/* Re-read symbols if a symbol-file has changed. */
void
reread_symbols (void)
Index: symfile.h
===================================================================
RCS file: /cvs/src/src/gdb/symfile.h,v
retrieving revision 1.20.2.1
diff -B -p -u -r1.20.2.1 symfile.h
--- symfile.h 18 May 2003 09:44:23 -0000 1.20.2.1
+++ symfile.h 20 May 2003 00:13:39 -0000
@@ -297,6 +297,12 @@ extern CORE_ADDR symbol_overlayed_addres
/* Load symbols from a file. */
extern void symbol_file_add_main (char *args, int from_tty);
+
+/* 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. */
+extern struct objfile *symbol_file_add_from_memory (bfd *templ, CORE_ADDR addr,
+ int from_tty);
/* Clear GDB symbol tables. */
extern void symbol_file_clear (int from_tty);
^ permalink raw reply [flat|nested] 40+ messages in thread* [PATCH] add-symbol-file-from-memory command
@ 2003-10-03 4:27 Roland McGrath
2003-10-03 21:41 ` Jim Blandy
0 siblings, 1 reply; 40+ messages in thread
From: Roland McGrath @ 2003-10-03 4:27 UTC (permalink / raw)
To: gdb-patches
I posted this originally back in May, and got no response whatsoever. I've
updated the patch to work with current mainline gdb and tested it again. I
hope there will be some response this time. This new user command is not
important, but this code needs review as it will form part of the support
for backtraces from system calls to work on Linux 2.6 kernels.
This adds a user command add-symbol-file-from-memory, which is like
add-symbol-file but takes just the address of an ELF header in inferior
memory (and no other args) instead of a file name.
This command may not really be worth having, but it serves to exercise the
underlying function symbol_file_add_from_memory. That function does the
work of reading symbols and unwind info from the Linux vsyscall DSO.
So please examine that new code.
This makes symfile.c call bfd_elf_bfd_from_remote_memory, which is
implemented in bfd/elf.c and so won't exist if there is no ELF target
backend configured into libbfd. I couldn't see any obvious place in gdb
that is conditionalized at compile-time on ELF; unless I'm missing
something elfread.c is always built in regardless of the presence of ELF
targets. Should I not be using this function in this file?
2003-10-02 Roland McGrath <roland@redhat.com>
* symfile.c (symbol_file_add_with_addrs_or_offsets): Take ABFD as
a new argument. Call symfile_bfd_open only if passed a null pointer.
(symbol_file_add, reread_separate_symbols): Update callers.
(build_addr_info): New function, helper for ...
(symbol_file_add_from_memory): New function.
(add_symbol_file_from_memory_command): New function using that.
(_initialize_symfile): Register it for add-symbol-file-from-memory.
* symfile.h (symbol_file_add_from_memory): Declare it.
Thanks,
Roland
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.109
diff -p -u -r1.109 symfile.c
--- symfile.c 21 Sep 2003 01:26:45 -0000 1.109
+++ symfile.c 3 Oct 2003 03:21:22 -0000
@@ -813,6 +813,10 @@ new_symfile_objfile (struct objfile *obj
NAME is the file name (which will be tilde-expanded and made
absolute herein) (but we don't free or modify NAME itself).
+ If ABFD is not null, it's already open and should be used instead of
+ opening the file by name. This BFD will be closed on error, and
+ is always consumed by this function.
+
FROM_TTY says how verbose to be.
MAINLINE specifies whether this is the main symbol file, or whether
@@ -825,7 +829,7 @@ new_symfile_objfile (struct objfile *obj
Upon success, returns a pointer to the objfile that was added.
Upon failure, jumps back to command level (never returns). */
static struct objfile *
-symbol_file_add_with_addrs_or_offsets (char *name, int from_tty,
+symbol_file_add_with_addrs_or_offsets (char *name, bfd *abfd, int from_tty,
struct section_addr_info *addrs,
struct section_offsets *offsets,
int num_offsets,
@@ -834,14 +838,16 @@ symbol_file_add_with_addrs_or_offsets (c
struct objfile *objfile;
struct partial_symtab *psymtab;
char *debugfile;
- bfd *abfd;
struct section_addr_info *orig_addrs;
struct cleanup *my_cleanups;
/* Open a bfd for the file, and give user a chance to burp if we'd be
interactively wiping out any existing symbols. */
- abfd = symfile_bfd_open (name);
+ if (abfd == NULL)
+ abfd = symfile_bfd_open (name);
+
+ my_cleanups = make_cleanup_bfd_close (abfd);
if ((have_full_symbols () || have_partial_symbols ())
&& mainline
@@ -850,6 +856,7 @@ symbol_file_add_with_addrs_or_offsets (c
error ("Not confirmed.");
objfile = allocate_objfile (abfd, flags);
+ discard_cleanups (my_cleanups);
orig_addrs = alloc_section_addr_info (bfd_count_sections (abfd));
my_cleanups = make_cleanup (xfree, orig_addrs);
@@ -987,7 +994,8 @@ struct objfile *
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 (name, from_tty, addrs, 0, 0,
+ return symbol_file_add_with_addrs_or_offsets (name, NULL, from_tty,
+ addrs, 0, 0,
mainline, flags);
}
@@ -1845,6 +1853,103 @@ add_shared_symbol_files_command (char *a
#endif
}
\f
+/* Helper function passed to bfd_map_over_sections. */
+static void
+build_addr_info (bfd *abfd, asection *sectp, void *info)
+{
+ struct section_addr_info *const sai = info;
+ unsigned int i = 0;
+
+ if ((bfd_get_section_flags (abfd, sectp) & (SEC_ALLOC|SEC_LOAD)) == 0)
+ return;
+
+ while (sai->other[i++].name != NULL)
+ if (i == sai->num_sections)
+ return;
+
+ sai->other[i].addr = bfd_get_section_vma (abfd, sectp);
+ sai->other[i].name = (char *) bfd_get_section_name (abfd, sectp);
+ sai->other[i].sectindex = sectp->index;
+}
+
+/* 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;
+ bfd_vma loadbase;
+ struct section_addr_info *sai;
+ unsigned int i;
+
+ if (from_tty)
+ {
+ if (bfd_get_flavour (templ) != bfd_target_elf_flavour)
+ error ("add-symbol-file-from-memory not supported for this target");
+ }
+ else
+ gdb_assert (bfd_get_flavour (templ) == bfd_target_elf_flavour);
+
+ nbfd = bfd_elf_bfd_from_remote_memory (templ, addr, &loadbase,
+ target_read_memory);
+ if (nbfd == NULL)
+ {
+ if (from_tty)
+ error ("Failed to read a valid object file image from memory.");
+ return NULL;
+ }
+
+ 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);
+ if (from_tty)
+ 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);
+ bfd_map_over_sections (nbfd, build_addr_info, sai);
+ for (i = 0; i < sai->num_sections && sai->other[i].name != NULL; ++i)
+ sai->other[i].addr += loadbase;
+
+ objf = symbol_file_add_with_addrs_or_offsets ("<in-memory>", nbfd, from_tty,
+ sai, NULL, 0, 0, 0);
+
+ 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.");
+
+ (void) symbol_file_add_from_memory (templ, addr, from_tty);
+}
+\f
/* Re-read symbols if a symbol-file has changed. */
void
reread_symbols (void)
@@ -2104,7 +2209,7 @@ reread_separate_symbols (struct objfile
Preserve the flags from objfile that make sense. */
objfile->separate_debug_objfile
= (symbol_file_add_with_addrs_or_offsets
- (debug_file,
+ (debug_file, NULL,
info_verbose, /* from_tty: Don't override the default. */
0, /* No addr table. */
objfile->section_offsets, objfile->num_sections,
@@ -2137,7 +2242,7 @@ add_filename_language (char *ext, enum l
@@ -3605,6 +3710,13 @@ with the text. SECT is a section name t
&cmdlist);
set_cmd_completer (c, filename_completer);
+ c = add_cmd ("add-symbol-file-from-memory", class_files,
+ add_symbol_file_from_memory_command,
+ "Usage: add-symbol-file-from-memory ADDR\n\
+Load the symbols out of memory from a dynamically loaded object file.\n\
+ADDR is the starting address of the file's shared object file header.",
+ &cmdlist);
+
c = add_cmd ("add-shared-symbol-files", class_files,
add_shared_symbol_files_command,
"Load the symbols from shared objects in the dynamic linker's link map.",
Index: symfile.h
===================================================================
RCS file: /cvs/src/src/gdb/symfile.h,v
retrieving revision 1.25
diff -p -u -r1.25 symfile.h
--- symfile.h 11 Sep 2003 19:49:19 -0000 1.25
+++ symfile.h 3 Oct 2003 03:21:22 -0000
@@ -306,6 +306,12 @@ extern CORE_ADDR symbol_overlayed_addres
/* Load symbols from a file. */
extern void symbol_file_add_main (char *args, int from_tty);
+/* 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. */
+extern struct objfile *symbol_file_add_from_memory (bfd *templ, CORE_ADDR addr,
+ int from_tty);
+
/* Clear GDB symbol tables. */
extern void symbol_file_clear (int from_tty);
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [PATCH] add-symbol-file-from-memory command
2003-10-03 4:27 Roland McGrath
@ 2003-10-03 21:41 ` Jim Blandy
2003-10-03 21:45 ` Daniel Jacobowitz
` (4 more replies)
0 siblings, 5 replies; 40+ messages in thread
From: Jim Blandy @ 2003-10-03 21:41 UTC (permalink / raw)
To: Roland McGrath
Cc: Mark Kettenis, Kevin Buettner, Daniel Jacobowitz, Andreas Schwab,
Scott Bambrough, gdb-patches
Roland McGrath <roland@redhat.com> writes:
> I posted this originally back in May, and got no response whatsoever. I've
> updated the patch to work with current mainline gdb and tested it again. I
> hope there will be some response this time. This new user command is not
> important, but this code needs review as it will form part of the support
> for backtraces from system calls to work on Linux 2.6 kernels.
This is important thing to get right; I'm sorry it wasn't reviewed
promptly back in May.
> This adds a user command add-symbol-file-from-memory, which is like
> add-symbol-file but takes just the address of an ELF header in inferior
> memory (and no other args) instead of a file name.
>
> This command may not really be worth having, but it serves to exercise the
> underlying function symbol_file_add_from_memory. That function does the
> work of reading symbols and unwind info from the Linux vsyscall DSO.
> So please examine that new code.
>
> This makes symfile.c call bfd_elf_bfd_from_remote_memory, which is
> implemented in bfd/elf.c and so won't exist if there is no ELF target
> backend configured into libbfd. I couldn't see any obvious place in gdb
> that is conditionalized at compile-time on ELF; unless I'm missing
> something elfread.c is always built in regardless of the presence of ELF
> targets. Should I not be using this function in this file?
It doesn't really belong in symfile.c. It's certainly Linux-specific
at the moment, so it belongs in a file specific to the Linux ABI, but
not specific to any processor (since all the architectures are going
to use the syscall ABI, not just i386, right?). The file linux-nat.c
isn't right, since it works fine over the remote protocol. I think we
need a new file, linux-tdep.c. Linux maintainers, what do you think?
The change itself looks fine. Reviewing it suggested various cleanups
to symfile.c (say, symbol_file_add_with_addrs_or_offsets should always
expect an opened BFD, and not take a name), but those are all
independent of what you're trying to accomplish here, and needn't hold
it up.
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [PATCH] add-symbol-file-from-memory command
2003-10-03 21:41 ` Jim Blandy
@ 2003-10-03 21:45 ` Daniel Jacobowitz
2003-10-03 22:08 ` Roland McGrath
` (3 subsequent siblings)
4 siblings, 0 replies; 40+ messages in thread
From: Daniel Jacobowitz @ 2003-10-03 21:45 UTC (permalink / raw)
To: Jim Blandy
Cc: Roland McGrath, Mark Kettenis, Kevin Buettner, Andreas Schwab,
Scott Bambrough, gdb-patches
On Fri, Oct 03, 2003 at 04:41:40PM -0500, Jim Blandy wrote:
>
> Roland McGrath <roland@redhat.com> writes:
> > I posted this originally back in May, and got no response whatsoever. I've
> > updated the patch to work with current mainline gdb and tested it again. I
> > hope there will be some response this time. This new user command is not
> > important, but this code needs review as it will form part of the support
> > for backtraces from system calls to work on Linux 2.6 kernels.
>
> This is important thing to get right; I'm sorry it wasn't reviewed
> promptly back in May.
>
> > This adds a user command add-symbol-file-from-memory, which is like
> > add-symbol-file but takes just the address of an ELF header in inferior
> > memory (and no other args) instead of a file name.
> >
> > This command may not really be worth having, but it serves to exercise the
> > underlying function symbol_file_add_from_memory. That function does the
> > work of reading symbols and unwind info from the Linux vsyscall DSO.
> > So please examine that new code.
> >
> > This makes symfile.c call bfd_elf_bfd_from_remote_memory, which is
> > implemented in bfd/elf.c and so won't exist if there is no ELF target
> > backend configured into libbfd. I couldn't see any obvious place in gdb
> > that is conditionalized at compile-time on ELF; unless I'm missing
> > something elfread.c is always built in regardless of the presence of ELF
> > targets. Should I not be using this function in this file?
>
> It doesn't really belong in symfile.c. It's certainly Linux-specific
> at the moment, so it belongs in a file specific to the Linux ABI, but
> not specific to any processor (since all the architectures are going
> to use the syscall ABI, not just i386, right?). The file linux-nat.c
> isn't right, since it works fine over the remote protocol. I think we
> need a new file, linux-tdep.c. Linux maintainers, what do you think?
I agree in general about creating a linux-tdep.c file, but I don't
think I agree that this code should be Linux specific. It's
ELF-specific, that much is true. But it would work just as well on
e.g. FreeBSD if they had some use for this mechanism, which they might
someday.
Why would you prefer it elsewhere?
> The change itself looks fine. Reviewing it suggested various cleanups
> to symfile.c (say, symbol_file_add_with_addrs_or_offsets should always
> expect an opened BFD, and not take a name), but those are all
> independent of what you're trying to accomplish here, and needn't hold
> it up.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [PATCH] add-symbol-file-from-memory command
2003-10-03 21:41 ` Jim Blandy
2003-10-03 21:45 ` Daniel Jacobowitz
@ 2003-10-03 22:08 ` Roland McGrath
2003-10-03 22:19 ` Elena Zannoni
` (2 subsequent siblings)
4 siblings, 0 replies; 40+ messages in thread
From: Roland McGrath @ 2003-10-03 22:08 UTC (permalink / raw)
To: Jim Blandy
Cc: Mark Kettenis, Kevin Buettner, Daniel Jacobowitz, Andreas Schwab,
Scott Bambrough, gdb-patches
> This is important thing to get right; I'm sorry it wasn't reviewed
> promptly back in May.
The apparent urgency it had then waned, so I stopped pushing on it and we
were all busy with other things. Only now is it really becoming important.
> It doesn't really belong in symfile.c. It's certainly Linux-specific
There is nothing Linux-specific about add-symbol-file-from-memory.
The implementation is ELF-specific, but the concept is not.
> The change itself looks fine. Reviewing it suggested various cleanups
> to symfile.c (say, symbol_file_add_with_addrs_or_offsets should always
> expect an opened BFD, and not take a name), but those are all
> independent of what you're trying to accomplish here, and needn't hold
> it up.
I am happy to do some cleanups while I'm in the area if it's clear what
ought to be done.
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [PATCH] add-symbol-file-from-memory command
2003-10-03 21:41 ` Jim Blandy
2003-10-03 21:45 ` Daniel Jacobowitz
2003-10-03 22:08 ` Roland McGrath
@ 2003-10-03 22:19 ` Elena Zannoni
2003-10-03 23:00 ` Roland McGrath
2003-10-03 22:34 ` Andrew Cagney
2003-10-06 15:30 ` Jim Blandy
4 siblings, 1 reply; 40+ messages in thread
From: Elena Zannoni @ 2003-10-03 22:19 UTC (permalink / raw)
To: Jim Blandy
Cc: Roland McGrath, Mark Kettenis, Kevin Buettner, Daniel Jacobowitz,
Andreas Schwab, Scott Bambrough, gdb-patches
Jim Blandy writes:
>
> Roland McGrath <roland@redhat.com> writes:
> > I posted this originally back in May, and got no response whatsoever. I've
> > updated the patch to work with current mainline gdb and tested it again. I
> > hope there will be some response this time. This new user command is not
> > important, but this code needs review as it will form part of the support
> > for backtraces from system calls to work on Linux 2.6 kernels.
>
> This is important thing to get right; I'm sorry it wasn't reviewed
> promptly back in May.
>
The reason being that there was no agreement on the prerequisites,
i.e. how to "do it right". There was no decision yet from the kernel
people either.
See also the binutils discussion about the bfd function.
elena
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2003-10-03 22:19 ` Elena Zannoni
@ 2003-10-03 23:00 ` Roland McGrath
2003-10-04 12:57 ` Elena Zannoni
0 siblings, 1 reply; 40+ messages in thread
From: Roland McGrath @ 2003-10-03 23:00 UTC (permalink / raw)
To: Elena Zannoni
Cc: Jim Blandy, Mark Kettenis, Kevin Buettner, Daniel Jacobowitz,
Andreas Schwab, Scott Bambrough, gdb-patches
> The reason being that there was no agreement on the prerequisites,
> i.e. how to "do it right". There was no decision yet from the kernel
> people either.
As I said in my later posting last night, this has now been resolved in
Linux 2.6 (the way we wanted it).
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2003-10-03 23:00 ` Roland McGrath
@ 2003-10-04 12:57 ` Elena Zannoni
2003-10-04 20:14 ` Roland McGrath
0 siblings, 1 reply; 40+ messages in thread
From: Elena Zannoni @ 2003-10-04 12:57 UTC (permalink / raw)
To: Roland McGrath
Cc: Elena Zannoni, Jim Blandy, Mark Kettenis, Kevin Buettner,
Daniel Jacobowitz, Andreas Schwab, Scott Bambrough, gdb-patches
Roland McGrath writes:
> > The reason being that there was no agreement on the prerequisites,
> > i.e. how to "do it right". There was no decision yet from the kernel
> > people either.
>
> As I said in my later posting last night, this has now been resolved in
> Linux 2.6 (the way we wanted it).
Yes.
I was more referring to the binutils mail thread starting at:
http://sources.redhat.com/ml/binutils/2003-05/msg00658.html which had
a rework of your function but was never finished, after several
comments. I.e. the interface/signature for that function is still in
flux.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2003-10-04 12:57 ` Elena Zannoni
@ 2003-10-04 20:14 ` Roland McGrath
2003-10-07 1:42 ` Andrew Cagney
0 siblings, 1 reply; 40+ messages in thread
From: Roland McGrath @ 2003-10-04 20:14 UTC (permalink / raw)
To: Elena Zannoni
Cc: Jim Blandy, Mark Kettenis, Kevin Buettner, Daniel Jacobowitz,
Andreas Schwab, Scott Bambrough, gdb-patches
> I was more referring to the binutils mail thread starting at:
> http://sources.redhat.com/ml/binutils/2003-05/msg00658.html which had
> a rework of your function but was never finished, after several
> comments. I.e. the interface/signature for that function is still in
> flux.
Jim has suggested a trivial cosmetic change to the interface of the
function. That can happen or not happen, and the meaningful affect on the
gdb work is epsilon (a one-minute update). I've already said the trivial
change Jim suggested is fine with me, and Jim has already posted a patch
that I have no complaints with and the only complaints I see are Andrew's
about choice of non-normative variable names (the height of triviality).
Andrew's assertion that this "unresolved issue" means that it's pointless
to review and discuss the rest of the code whose use of this interface will
not differ meaningfully regardless of any likely change, is simply
ludicrous. If you and/or Andrew don't want to be of any help in hashing
out the implementation work that actually does still need to be done, fine.
Fortunately other gdb hackers are willing to review code meaningfully
rather than evade and bicker. I am happy to work with whomever is inclined
to help.
Thanks,
Roland
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2003-10-03 21:41 ` Jim Blandy
` (2 preceding siblings ...)
2003-10-03 22:19 ` Elena Zannoni
@ 2003-10-03 22:34 ` Andrew Cagney
2003-10-03 23:02 ` Roland McGrath
2003-10-06 15:30 ` Jim Blandy
4 siblings, 1 reply; 40+ messages in thread
From: Andrew Cagney @ 2003-10-03 22:34 UTC (permalink / raw)
To: Jim Blandy
Cc: Roland McGrath, Mark Kettenis, Kevin Buettner, Daniel Jacobowitz,
Andreas Schwab, Scott Bambrough, gdb-patches
> Roland McGrath <roland@redhat.com> writes:
>
>> I posted this originally back in May, and got no response whatsoever. I've
>> updated the patch to work with current mainline gdb and tested it again. I
>> hope there will be some response this time. This new user command is not
>> important, but this code needs review as it will form part of the support
>> for backtraces from system calls to work on Linux 2.6 kernels.
>
>
> This is important thing to get right; I'm sorry it wasn't reviewed
> promptly back in May.
FYI
An upstream BFD problem, on which this patch depends, wasn't resolved.
Consequently, there there was no reason to review the patch - Roland
should be aware of this since it was Roland's upstream BFD change that
wasn't resolved.
(Jim, you should remember this, it's where the word "closure" came from).
Andrew
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [PATCH] add-symbol-file-from-memory command
2003-10-03 22:34 ` Andrew Cagney
@ 2003-10-03 23:02 ` Roland McGrath
2003-10-04 14:39 ` Andrew Cagney
0 siblings, 1 reply; 40+ messages in thread
From: Roland McGrath @ 2003-10-03 23:02 UTC (permalink / raw)
To: Andrew Cagney
Cc: Jim Blandy, Mark Kettenis, Kevin Buettner, Daniel Jacobowitz,
Andreas Schwab, Scott Bambrough, gdb-patches
> An upstream BFD problem, on which this patch depends, wasn't resolved.
> Consequently, there there was no reason to review the patch - Roland
> should be aware of this since it was Roland's upstream BFD change that
> wasn't resolved.
What is unresolved? My bfd_elf_bfd_from_remote_memory implementation was
approved and committed to bfd in May. The code in the current binutils cvs
works fine for me as the basis for the gdb patches I have recently posted.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2003-10-03 23:02 ` Roland McGrath
@ 2003-10-04 14:39 ` Andrew Cagney
0 siblings, 0 replies; 40+ messages in thread
From: Andrew Cagney @ 2003-10-04 14:39 UTC (permalink / raw)
To: Roland McGrath, Jim Blandy; +Cc: gdb-patches
[CC trimmed, not sure what the point was]
>> An upstream BFD problem, on which this patch depends, wasn't resolved.
>> Consequently, there there was no reason to review the patch - Roland
>> should be aware of this since it was Roland's upstream BFD change that
>> wasn't resolved.
>
>
> What is unresolved? My bfd_elf_bfd_from_remote_memory implementation was
> approved and committed to bfd in May. The code in the current binutils cvs
> works fine for me as the basis for the gdb patches I have recently posted.
See Elena's pointer into that thread.
That code, in its current form, can only be described as a "work in
progress".
Andrew
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2003-10-03 21:41 ` Jim Blandy
` (3 preceding siblings ...)
2003-10-03 22:34 ` Andrew Cagney
@ 2003-10-06 15:30 ` Jim Blandy
2003-10-06 15:43 ` Daniel Jacobowitz
4 siblings, 1 reply; 40+ messages in thread
From: Jim Blandy @ 2003-10-06 15:30 UTC (permalink / raw)
To: Roland McGrath; +Cc: Daniel Jacobowitz, gdb-patches
It seems I'm confused about where the vsyscall support is useful. I
thought it was Linux-specific, but folks disagreed. I think it's
important to get this right, because that determines where the code
goes in GDB and what the interfaces are.
(This message rambles in a whiney sort of way, and then asks specific
questions at bottom.)
One of the sources of my confusion is whether it's Linux-specific or
ELF-specific. The vsyscall DSO only appears on Linux --- at the
moment. But supporting it in GDB can be done without reference to
anything Linux-specific: you need to check the auxilliary vector (an
ELF thing) and read an ELF file out of memory. It never makes
Linux-specific system calls, or relies on Linux-specific filesystem
layout stuff, for example. So leaving linux-tdep.c and
config/nm-linux.h out of the picture entirely, and doing everything as
ELF-related code, will not introduce any interface violations.
But although I understand that the Linux system call interface is
changing, and that the new interface requires the kernel to provide
unwinding information, because the old way of unwinding from system
calls no longer works, I've never understood why the system call
interface had to change in the first place.
In a sense, it's irrelevant --- the interface *is* changing, and GDB
must continue to work. But not understanding why the system call
interface must change makes it difficult for me to assess how likely
other systems are to adopt vsyscall DSO's, and thus whether it's
better to isolate the additional complexity to Linux-specific files,
even though the work is portable to all ELF targets, or whether it's
better to make it ELF-specific, to make it easy (or unnecessary) to
adapt GDB when the feature appears elsewhere.
I think there's a good argument that one should simply always
implement everything using the smallest interface you can stand, even
if it's only used in a specific situation, because it makes the code
easier to reuse. Since the vsyscall DSO support only really depends
on ELF stuff, and it automatically detects when it's needed (by the
presence of a specific element in the auxilliary vector), maybe that's
the best thing to do.
So, why did the kernel system call interface need to change? How
likely are other Unices to begin using vsyscall DSO's? I've seen
x86-64 and IA-64 mentioned; would it be useful on PPC and the S/390,
too? (Just to pick random architectures out of the air.)
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [PATCH] add-symbol-file-from-memory command
2003-10-06 15:30 ` Jim Blandy
@ 2003-10-06 15:43 ` Daniel Jacobowitz
2003-10-06 19:57 ` Roland McGrath
2003-10-07 23:32 ` Michael Snyder
0 siblings, 2 replies; 40+ messages in thread
From: Daniel Jacobowitz @ 2003-10-06 15:43 UTC (permalink / raw)
To: Jim Blandy; +Cc: Roland McGrath, gdb-patches
On Mon, Oct 06, 2003 at 10:29:05AM -0500, Jim Blandy wrote:
>
> It seems I'm confused about where the vsyscall support is useful. I
> thought it was Linux-specific, but folks disagreed. I think it's
> important to get this right, because that determines where the code
> goes in GDB and what the interfaces are.
No, I agree with you that vsyscalls are Linux-specific - for now at
least. But I think that the concept of add-symbol-file-from-memory is
well separated from the concept of vsyscalls. It seems like a useful
thing to have for interacting with, say, a hypothetical minimalist ELF
shared loader.
> (This message rambles in a whiney sort of way, and then asks specific
> questions at bottom.)
>
> One of the sources of my confusion is whether it's Linux-specific or
> ELF-specific. The vsyscall DSO only appears on Linux --- at the
> moment. But supporting it in GDB can be done without reference to
> anything Linux-specific: you need to check the auxilliary vector (an
> ELF thing) and read an ELF file out of memory. It never makes
> Linux-specific system calls, or relies on Linux-specific filesystem
> layout stuff, for example. So leaving linux-tdep.c and
> config/nm-linux.h out of the picture entirely, and doing everything as
> ELF-related code, will not introduce any interface violations.
Except that the AT_SYSINFO tag is really Linux-specific. There's no
guarantee that nothing else would use the same auxv tag for something
else. I don't believe they're centrally registered, since they're
ultimately system-specific by nature.
> But although I understand that the Linux system call interface is
> changing, and that the new interface requires the kernel to provide
> unwinding information, because the old way of unwinding from system
> calls no longer works, I've never understood why the system call
> interface had to change in the first place.
>
> In a sense, it's irrelevant --- the interface *is* changing, and GDB
> must continue to work. But not understanding why the system call
> interface must change makes it difficult for me to assess how likely
> other systems are to adopt vsyscall DSO's, and thus whether it's
> better to isolate the additional complexity to Linux-specific files,
> even though the work is portable to all ELF targets, or whether it's
> better to make it ELF-specific, to make it easy (or unnecessary) to
> adapt GDB when the feature appears elsewhere.
>
> I think there's a good argument that one should simply always
> implement everything using the smallest interface you can stand, even
> if it's only used in a specific situation, because it makes the code
> easier to reuse. Since the vsyscall DSO support only really depends
> on ELF stuff, and it automatically detects when it's needed (by the
> presence of a specific element in the auxilliary vector), maybe that's
> the best thing to do.
>
>
> So, why did the kernel system call interface need to change? How
> likely are other Unices to begin using vsyscall DSO's? I've seen
> x86-64 and IA-64 mentioned; would it be useful on PPC and the S/390,
> too? (Just to pick random architectures out of the air.)
This is all "as I understand it". Feel free to correct, anyone.
The original motivation for x86 was that we have three different
mechanisms for making a syscall:
- int $80
- sysenter
- syscall
It turns out that int $80 isn't the best way any more, on some
processors. sysenter (?) is much faster. But changing the syscall
interface is something that has to be done very delicately.... so the
"new" way of doing syscalls isn't using sysenter, which wouldn't work
everywhere etc. It's "jump to this address in a preloaded DSO, on a
kernel-mapped high memory page". It's simple, powerful, extensible.
The kernel can do other neat things with it too. For ia64 there's been
discussion of lightweight syscalls which can be implemented entirely
within that page. Gettimeofday is the best example. I think there are
some synchronization etc. issues with this (plus you lose strace
ability if you're not careful!) so it hasn't been done yet.
And this page can also be used for signal trampolines, and is on some
architectures. Which is a beauteous and wonderful thing, because it
can provide DWARF-2 CFI information for the signal trampoline.
I suspect at least the signal trampolines and lightweight syscalls
could be useful on other architectures also.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2003-10-06 15:43 ` Daniel Jacobowitz
@ 2003-10-06 19:57 ` Roland McGrath
2003-10-07 23:32 ` Michael Snyder
1 sibling, 0 replies; 40+ messages in thread
From: Roland McGrath @ 2003-10-06 19:57 UTC (permalink / raw)
To: Jim Blandy; +Cc: Daniel Jacobowitz, gdb-patches
Dan is right on the money, as usual. As to why the entry point page was
added on x86, correct: int $0x80 is the traditional Linux/x86 system call
ABI and still works of course; newer x86 processors support "sysenter",
which enters kernel mode without saving state in a normal trap frame and
takes many fewer cycles than the normal trap path "int N" uses; AMD64
processors running 32-bit x86 code support "syscall", which is similarly
cheaper and more constrained on the kernel side than a vanilla trap.
(There is not at the moment a vsyscall DSO for native AMD64 processes. I
may have said or implied there was, because that's what I'd been thinking.
In fact, there is a kernel entry page in a different form that probably
will need to be revamped into the same vsyscall DSO plan to support
unwinding properly.) On the ia64 there is analogously a new and spiffier
way to enter the kernel than the old "break" instruction (the generic trap
requester instruction): it has a really cool feature, wherein there is an
extra kind of permission bit in the page tables that permits code on that
page to execute the magic "epc" instruction, which puts the processor in a
special semiprivileged mode without the overhead of a normal trap into
kernel mode, letting it access kernel memory and some other such things
that might suffice for a given system call's implementation (and then
return to normal user mode again) while never fully reloading some kinds of
internal state a normal trap would do. I don't know enough about any other
processor off hand to speculate whether a similar new generic kernel-entry
mechanism might come in there. But, as Dan has pointed out, there are
various system calls that can be optimized by implementing them in
kernel-supplied code that runs purely in user mode (such techniques are
well-travelled in research kernels); so it is reasonable to speculate that
such a DSO might one day be use on any given machine.
Dan is also correct in his identification of the portability issues. The
auxv arrangement, including NT_AUXV and /proc/*/auxv, is common to almost
every ELF-based Unix-like platform; the stack layout (not the access methods
AFAIK) is part of every SVR4 ABI spec, though not strictly within the
purview of the ELF format spec itself. (AFAIK only GNU/Hurd doesn't use
AT_*. Though AFAIK only Linux 2.6 and Solaris support NT_AUXV and
/proc/*/auxv, I am not aware of any system providing a different interface
for getting that information; i.e. things support those or nothing.)
However, the AT_* values (except for AT_NULL==0) are neither standardized
nor de facto reliably the same across operating systems (they are part of
the SVR4 ABI spec for each processor I believe). The values in
include/elf/common.h are copied from glibc's <elf.h>, and are what GNU/Linux
uses. Some of the values used on Solaris conflict, though Sun seems to have
taken to using AT_SUN_* names and values >=2000 for recent additions and so
it now seems unlikely they will use values 32 or 33 and thus risk false
matches with the Linux AT_SYSINFO_EHDR tag. (FYI, NetBSD's elf.h header has
all of Sun's values and no GNU/Linux values; however NetBSD itself uses only
the tags <10 which in fact match exactly everywhere.)
So the actual call checking for AT_SYSINFO_EHDR belongs in linux-tdep (and
added separately to other OS-tdep's if any other systems follow suit). But
there's no reason the code that does the real work shouldn't be in shared
or generic ELF-specific places so that the OS-tdep portion is just a line
or two. The add-symbol-file-from-memory command is the larger chunk of
that work. Its extant implementation is ELF-specific, but the notion is
not; so, consistent with other gdb features, it would make sense for the
command to exist but fail with "not supported on this target" for non-ELF
targets. Where the other part of the work (AT_SYSINFO_EHDR checking)
belongs we can pick up in the other thread, which is where this message
really belonged too.
Thanks,
Roland
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2003-10-06 15:43 ` Daniel Jacobowitz
2003-10-06 19:57 ` Roland McGrath
@ 2003-10-07 23:32 ` Michael Snyder
1 sibling, 0 replies; 40+ messages in thread
From: Michael Snyder @ 2003-10-07 23:32 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Jim Blandy, Roland McGrath, gdb-patches
Daniel Jacobowitz wrote:
> On Mon, Oct 06, 2003 at 10:29:05AM -0500, Jim Blandy wrote:
>
>>It seems I'm confused about where the vsyscall support is useful. I
>>thought it was Linux-specific, but folks disagreed. I think it's
>>important to get this right, because that determines where the code
>>goes in GDB and what the interfaces are.
>
>
> No, I agree with you that vsyscalls are Linux-specific - for now at
> least. But I think that the concept of add-symbol-file-from-memory is
> well separated from the concept of vsyscalls. It seems like a useful
> thing to have for interacting with, say, a hypothetical minimalist ELF
> shared loader.
>
>
>>(This message rambles in a whiney sort of way, and then asks specific
>>questions at bottom.)
>>
>>One of the sources of my confusion is whether it's Linux-specific or
>>ELF-specific. The vsyscall DSO only appears on Linux --- at the
>>moment. But supporting it in GDB can be done without reference to
>>anything Linux-specific: you need to check the auxilliary vector (an
>>ELF thing) and read an ELF file out of memory. It never makes
>>Linux-specific system calls, or relies on Linux-specific filesystem
>>layout stuff, for example. So leaving linux-tdep.c and
>>config/nm-linux.h out of the picture entirely, and doing everything as
>>ELF-related code, will not introduce any interface violations.
>
>
> Except that the AT_SYSINFO tag is really Linux-specific. There's no
> guarantee that nothing else would use the same auxv tag for something
> else. I don't believe they're centrally registered, since they're
> ultimately system-specific by nature.
>
>
>>But although I understand that the Linux system call interface is
>>changing, and that the new interface requires the kernel to provide
>>unwinding information, because the old way of unwinding from system
>>calls no longer works, I've never understood why the system call
>>interface had to change in the first place.
>>
>>In a sense, it's irrelevant --- the interface *is* changing, and GDB
>>must continue to work. But not understanding why the system call
>>interface must change makes it difficult for me to assess how likely
>>other systems are to adopt vsyscall DSO's, and thus whether it's
>>better to isolate the additional complexity to Linux-specific files,
>>even though the work is portable to all ELF targets, or whether it's
>>better to make it ELF-specific, to make it easy (or unnecessary) to
>>adapt GDB when the feature appears elsewhere.
>>
>>I think there's a good argument that one should simply always
>>implement everything using the smallest interface you can stand, even
>>if it's only used in a specific situation, because it makes the code
>>easier to reuse. Since the vsyscall DSO support only really depends
>>on ELF stuff, and it automatically detects when it's needed (by the
>>presence of a specific element in the auxilliary vector), maybe that's
>>the best thing to do.
>>
>>
>>So, why did the kernel system call interface need to change? How
>>likely are other Unices to begin using vsyscall DSO's? I've seen
>>x86-64 and IA-64 mentioned; would it be useful on PPC and the S/390,
>>too? (Just to pick random architectures out of the air.)
>
>
> This is all "as I understand it". Feel free to correct, anyone.
>
> The original motivation for x86 was that we have three different
> mechanisms for making a syscall:
> - int $80
> - sysenter
> - syscall
>
> It turns out that int $80 isn't the best way any more, on some
> processors. sysenter (?) is much faster. But changing the syscall
> interface is something that has to be done very delicately.... so the
> "new" way of doing syscalls isn't using sysenter, which wouldn't work
> everywhere etc. It's "jump to this address in a preloaded DSO, on a
> kernel-mapped high memory page". It's simple, powerful, extensible.
>
> The kernel can do other neat things with it too. For ia64 there's been
> discussion of lightweight syscalls which can be implemented entirely
> within that page. Gettimeofday is the best example. I think there are
> some synchronization etc. issues with this (plus you lose strace
> ability if you're not careful!) so it hasn't been done yet.
>
> And this page can also be used for signal trampolines, and is on some
> architectures. Which is a beauteous and wonderful thing, because it
> can provide DWARF-2 CFI information for the signal trampoline.
>
> I suspect at least the signal trampolines and lightweight syscalls
> could be useful on other architectures also.
>
So, coming late to the discussion, is it fair to summarize that
a consensus is emerging that this is good and needful functionality,
which should go into gdb, pending only the resolution of a few
naming and placement issues?
^ permalink raw reply [flat|nested] 40+ messages in thread
* [PATCH] add-symbol-file-from-memory command
@ 2004-02-02 3:38 Roland McGrath
2004-02-02 4:06 ` Daniel Jacobowitz
2004-02-02 6:19 ` Eli Zaretskii
0 siblings, 2 replies; 40+ messages in thread
From: Roland McGrath @ 2004-02-02 3:38 UTC (permalink / raw)
To: gdb-patches
This patch hasn't changed since the last time I posted it. But I'm hoping
that it will be approved this time. This support (the underlying function,
not the user command) is the last nontrivial piece required for backtraces
from system calls to work right with vanilla Linux 2.6 kernels. The only
objections previously were not apropos, and noone said anything about the
content of the code itself. If there is valid cause not to put this in
now, I hope I can see it stated clearly.
The last time around, some said bfd_elf_bfd_from_remote_memory function was
"in flux" or "a work in progress". That function is fine as it is in BFD
and has sat there without change for a long time. If anyone intends to
change its calling convention, updating gdb to suit will be at most three
minutes work. Since the current BFD code was approved for commit as it is,
I can't see how speculations about possible future changes there warrant
holding up this gdb change now.
I've made fresh diffs here, after testing this code with today's mainline
gdb. It still works just fine.
Thanks,
Roland
2003-10-02 Roland McGrath <roland@redhat.com>
* symfile.c (symbol_file_add_with_addrs_or_offsets): Take ABFD as
a new argument. Call symfile_bfd_open only if passed a null pointer.
(symbol_file_add, reread_separate_symbols): Update callers.
(build_addr_info): New function, helper for ...
(symbol_file_add_from_memory): New function.
(add_symbol_file_from_memory_command): New function using that.
(_initialize_symfile): Register it for add-symbol-file-from-memory.
* symfile.h (symbol_file_add_from_memory): Declare it.
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.117
diff -b -p -u -r1.117 symfile.c
--- symfile.c 23 Jan 2004 17:56:46 -0000 1.117
+++ symfile.c 2 Feb 2004 03:23:23 -0000
@@ -799,6 +799,10 @@ new_symfile_objfile (struct objfile *obj
NAME is the file name (which will be tilde-expanded and made
absolute herein) (but we don't free or modify NAME itself).
+ If ABFD is not null, it's already open and should be used instead of
+ opening the file by name. This BFD will be closed on error, and
+ is always consumed by this function.
+
FROM_TTY says how verbose to be.
MAINLINE specifies whether this is the main symbol file, or whether
@@ -811,7 +815,7 @@ new_symfile_objfile (struct objfile *obj
Upon success, returns a pointer to the objfile that was added.
Upon failure, jumps back to command level (never returns). */
static struct objfile *
-symbol_file_add_with_addrs_or_offsets (char *name, int from_tty,
+symbol_file_add_with_addrs_or_offsets (char *name, bfd *abfd, int from_tty,
struct section_addr_info *addrs,
struct section_offsets *offsets,
int num_offsets,
@@ -820,15 +824,17 @@ symbol_file_add_with_addrs_or_offsets (c
struct objfile *objfile;
struct partial_symtab *psymtab;
char *debugfile;
- bfd *abfd;
struct section_addr_info *orig_addrs;
struct cleanup *my_cleanups;
/* Open a bfd for the file, and give user a chance to burp if we'd be
interactively wiping out any existing symbols. */
+ if (abfd == NULL)
abfd = symfile_bfd_open (name);
+ my_cleanups = make_cleanup_bfd_close (abfd);
+
if ((have_full_symbols () || have_partial_symbols ())
&& mainline
&& from_tty
@@ -836,6 +842,7 @@ symbol_file_add_with_addrs_or_offsets (c
error ("Not confirmed.");
objfile = allocate_objfile (abfd, flags);
+ discard_cleanups (my_cleanups);
orig_addrs = alloc_section_addr_info (bfd_count_sections (abfd));
my_cleanups = make_cleanup (xfree, orig_addrs);
@@ -952,7 +959,8 @@ struct objfile *
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 (name, from_tty, addrs, 0, 0,
+ return symbol_file_add_with_addrs_or_offsets (name, NULL, from_tty,
+ addrs, 0, 0,
mainline, flags);
}
@@ -1802,6 +1810,106 @@ add_shared_symbol_files_command (char *a
#endif
}
\f
+/* Helper function passed to bfd_map_over_sections. */
+static void
+build_addr_info (bfd *abfd, asection *sectp, void *info)
+{
+ struct section_addr_info *const sai = info;
+ unsigned int i = 0;
+
+ if ((bfd_get_section_flags (abfd, sectp) & (SEC_ALLOC|SEC_LOAD)) == 0)
+ return;
+
+ while (sai->other[i++].name != NULL)
+ if (i == sai->num_sections)
+ return;
+
+ sai->other[i].addr = bfd_get_section_vma (abfd, sectp);
+ sai->other[i].name = (char *) bfd_get_section_name (abfd, sectp);
+ sai->other[i].sectindex = sectp->index;
+}
+
+/* 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;
+ bfd_vma loadbase;
+ struct section_addr_info *sai;
+ unsigned int i;
+
+ if (from_tty)
+ {
+ if (bfd_get_flavour (templ) != bfd_target_elf_flavour)
+ error ("add-symbol-file-from-memory not supported for this target");
+ }
+ else
+ gdb_assert (bfd_get_flavour (templ) == bfd_target_elf_flavour);
+
+ nbfd = bfd_elf_bfd_from_remote_memory (templ, addr, &loadbase,
+ target_read_memory);
+ if (nbfd == NULL)
+ {
+ if (from_tty)
+ 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);
+ if (from_tty)
+ 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);
+ bfd_map_over_sections (nbfd, build_addr_info, sai);
+ for (i = 0; i < sai->num_sections && sai->other[i].name != NULL; ++i)
+ sai->other[i].addr += loadbase;
+
+ objf = symbol_file_add_with_addrs_or_offsets ((char *) nbfd->filename, nbfd,
+ from_tty, sai, NULL, 0, 0,
+ OBJF_SHARED);
+
+ 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.");
+
+ (void) symbol_file_add_from_memory (templ, addr, from_tty);
+}
+\f
/* Re-read symbols if a symbol-file has changed. */
void
reread_symbols (void)
@@ -2063,7 +2171,7 @@ reread_separate_symbols (struct objfile
Preserve the flags from objfile that make sense. */
objfile->separate_debug_objfile
= (symbol_file_add_with_addrs_or_offsets
- (debug_file,
+ (debug_file, NULL,
info_verbose, /* from_tty: Don't override the default. */
0, /* No addr table. */
objfile->section_offsets, objfile->num_sections,
@@ -3566,6 +3674,13 @@ with the text. SECT is a section name t
&cmdlist);
set_cmd_completer (c, filename_completer);
+ c = add_cmd ("add-symbol-file-from-memory", class_files,
+ add_symbol_file_from_memory_command,
+ "Usage: add-symbol-file-from-memory ADDR\n\
+Load the symbols out of memory from a dynamically loaded object file.\n\
+ADDR is the starting address of the file's shared object file header.",
+ &cmdlist);
+
c = add_cmd ("add-shared-symbol-files", class_files,
add_shared_symbol_files_command,
"Load the symbols from shared objects in the dynamic linker's link map.",
Index: symfile.h
===================================================================
RCS file: /cvs/src/src/gdb/symfile.h,v
retrieving revision 1.25
diff -b -p -u -r1.25 symfile.h
--- symfile.h 11 Sep 2003 19:49:19 -0000 1.25
+++ symfile.h 2 Feb 2004 03:23:23 -0000
@@ -306,6 +306,12 @@ extern CORE_ADDR symbol_overlayed_addres
/* Load symbols from a file. */
extern void symbol_file_add_main (char *args, int from_tty);
+/* 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. */
+extern struct objfile *symbol_file_add_from_memory (bfd *templ, CORE_ADDR addr,
+ int from_tty);
+
/* Clear GDB symbol tables. */
extern void symbol_file_clear (int from_tty);
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [PATCH] add-symbol-file-from-memory command
2004-02-02 3:38 Roland McGrath
@ 2004-02-02 4:06 ` Daniel Jacobowitz
2004-02-02 4:47 ` Roland McGrath
2004-02-02 6:19 ` Eli Zaretskii
1 sibling, 1 reply; 40+ messages in thread
From: Daniel Jacobowitz @ 2004-02-02 4:06 UTC (permalink / raw)
To: Roland McGrath; +Cc: gdb-patches
On Sun, Feb 01, 2004 at 07:38:26PM -0800, Roland McGrath wrote:
> This patch hasn't changed since the last time I posted it. But I'm hoping
> that it will be approved this time. This support (the underlying function,
> not the user command) is the last nontrivial piece required for backtraces
> from system calls to work right with vanilla Linux 2.6 kernels. The only
> objections previously were not apropos, and noone said anything about the
> content of the code itself. If there is valid cause not to put this in
> now, I hope I can see it stated clearly.
>
> The last time around, some said bfd_elf_bfd_from_remote_memory function was
> "in flux" or "a work in progress". That function is fine as it is in BFD
> and has sat there without change for a long time. If anyone intends to
> change its calling convention, updating gdb to suit will be at most three
> minutes work. Since the current BFD code was approved for commit as it is,
> I can't see how speculations about possible future changes there warrant
> holding up this gdb change now.
>
> I've made fresh diffs here, after testing this code with today's mainline
> gdb. It still works just fine.
I can't approve this patch, but I have some comments anyway.
I can tell you one problem with this patch, based on my backport of it:
there's an annoying/incorrect message when a program is re-run, saying:
"<in-memory>" has disappeared; keeping its symbols
This is merely an annoyance, the message is harmless but should be
fixed.
There also was a segfault when the objfile is released. To reproduce,
I could just say "file\n" after loading one. GDB will try to
xfree("<in-memory>"). I see that this is fixed in the patch below, so
if the bits were unchanged from your last post then I must have come up
with the wrong copy.
> @@ -1802,6 +1810,106 @@ add_shared_symbol_files_command (char *a
> #endif
> }
> \f
> +/* Helper function passed to bfd_map_over_sections. */
> +static void
> +build_addr_info (bfd *abfd, asection *sectp, void *info)
> +{
> + struct section_addr_info *const sai = info;
> + unsigned int i = 0;
> +
> + if ((bfd_get_section_flags (abfd, sectp) & (SEC_ALLOC|SEC_LOAD)) == 0)
> + return;
> +
> + while (sai->other[i++].name != NULL)
> + if (i == sai->num_sections)
> + return;
> +
> + sai->other[i].addr = bfd_get_section_vma (abfd, sectp);
> + sai->other[i].name = (char *) bfd_get_section_name (abfd, sectp);
> + sai->other[i].sectindex = sectp->index;
> +}
Mind doing this in some way that isn't gratuitously quadratic? From
the BFD manual aout bfd_map_over_sections:
This is the preferred method for iterating over sections; an
alternative would be to use a loop:
| section *p;
| for (p = abfd->sections; p != NULL; p = p->next)
| func (abfd, p, ...)
so the ->next chain is a documented interface.
> + if (from_tty)
> + {
> + if (bfd_get_flavour (templ) != bfd_target_elf_flavour)
> + error ("add-symbol-file-from-memory not supported for this target");
> + }
> + else
> + gdb_assert (bfd_get_flavour (templ) == bfd_target_elf_flavour);
Please remove the check and the !from_tty branch. An error is fine in
either case, and internal errors are not appropriate for user input.
Further down you have different error behavior on !from_tty also. Is
there a particular inspiration for this?
> + reinit_frame_cache (); /* ??? */
Yes, this is necessary if the current cached backtrace would pass
through the newly loaded object.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [PATCH] add-symbol-file-from-memory command
2004-02-02 4:06 ` Daniel Jacobowitz
@ 2004-02-02 4:47 ` Roland McGrath
2004-02-02 15:02 ` Daniel Jacobowitz
0 siblings, 1 reply; 40+ messages in thread
From: Roland McGrath @ 2004-02-02 4:47 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
> I can't approve this patch, but I have some comments anyway.
Much appreciated.
> There also was a segfault when the objfile is released. To reproduce,
> I could just say "file\n" after loading one. GDB will try to
> xfree("<in-memory>"). I see that this is fixed in the patch below, so
> if the bits were unchanged from your last post then I must have come up
> with the wrong copy.
I won't testify to not having noticed and fixed (and since forgotten) some
small bug like this between the last time I posted and today. Probably I did.
> I can tell you one problem with this patch, based on my backport of it:
> there's an annoying/incorrect message when a program is re-run, saying:
> "<in-memory>" has disappeared; keeping its symbols
>
> This is merely an annoyance, the message is harmless but should be
> fixed.
I don't see this. AFAICT it just loses the symbols, like it should. What
exactly is the recipe for seeing this? This may be something else I forgot
I changed. It sets the OBJF_SHARED flag, which means the objfile is
dropped by objfile_purge_solibs for "run".
> Mind doing this in some way that isn't gratuitously quadratic?
Sure. I only used bfd_map_over_sections since it was said to be preferred.
> Please remove the check and the !from_tty branch. An error is fine in
> either case, and internal errors are not appropriate for user input.
> Further down you have different error behavior on !from_tty also. Is
> there a particular inspiration for this?
My thinking was that when there are later internal calls to this function
from target code, it would be an indication of a bug in the target code if
it ever got called for a non-ELF target, and those would be the called with
from_tty==0, hence the gdb_assert. The other errors indicate that the
thing was reasonable to attempt, but failed. I think I copied the from_tty
conditional for those errors from some other code I found similar, but I
may be misremembering. I am more than happy to have you tell me a clear
policy on what from_tty should or shouldn't affect.
> > + reinit_frame_cache (); /* ??? */
>
> Yes, this is necessary if the current cached backtrace would pass
> through the newly loaded object.
I appreciate the explanation. I've added a comment.
I'm appending my current version of the symfile.c part of the patch.
Thanks,
Roland
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.117
diff -u -b -p -r1.117 symfile.c
--- symfile.c 23 Jan 2004 17:56:46 -0000 1.117
+++ symfile.c 2 Feb 2004 04:41:50 -0000
@@ -799,6 +799,10 @@ new_symfile_objfile (struct objfile *obj
NAME is the file name (which will be tilde-expanded and made
absolute herein) (but we don't free or modify NAME itself).
+ If ABFD is not null, it's already open and should be used instead of
+ opening the file by name. This BFD will be closed on error, and
+ is always consumed by this function.
+
FROM_TTY says how verbose to be.
MAINLINE specifies whether this is the main symbol file, or whether
@@ -811,7 +815,7 @@ new_symfile_objfile (struct objfile *obj
Upon success, returns a pointer to the objfile that was added.
Upon failure, jumps back to command level (never returns). */
static struct objfile *
-symbol_file_add_with_addrs_or_offsets (char *name, int from_tty,
+symbol_file_add_with_addrs_or_offsets (char *name, bfd *abfd, int from_tty,
struct section_addr_info *addrs,
struct section_offsets *offsets,
int num_offsets,
@@ -820,15 +824,17 @@ symbol_file_add_with_addrs_or_offsets (c
struct objfile *objfile;
struct partial_symtab *psymtab;
char *debugfile;
- bfd *abfd;
struct section_addr_info *orig_addrs;
struct cleanup *my_cleanups;
/* Open a bfd for the file, and give user a chance to burp if we'd be
interactively wiping out any existing symbols. */
+ if (abfd == NULL)
abfd = symfile_bfd_open (name);
+ my_cleanups = make_cleanup_bfd_close (abfd);
+
if ((have_full_symbols () || have_partial_symbols ())
&& mainline
&& from_tty
@@ -836,6 +842,7 @@ symbol_file_add_with_addrs_or_offsets (c
error ("Not confirmed.");
objfile = allocate_objfile (abfd, flags);
+ discard_cleanups (my_cleanups);
orig_addrs = alloc_section_addr_info (bfd_count_sections (abfd));
my_cleanups = make_cleanup (xfree, orig_addrs);
@@ -952,7 +959,8 @@ struct objfile *
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 (name, from_tty, addrs, 0, 0,
+ return symbol_file_add_with_addrs_or_offsets (name, NULL, from_tty,
+ addrs, 0, 0,
mainline, flags);
}
@@ -1802,6 +1810,90 @@ add_shared_symbol_files_command (char *a
#endif
}
\f
+/* 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)
+ {
+ if (from_tty)
+ 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);
+ if (from_tty)
+ 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 ((char *) nbfd->filename, nbfd,
+ from_tty, sai, NULL, 0, 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.");
+
+ (void) symbol_file_add_from_memory (templ, addr, from_tty);
+}
+\f
/* Re-read symbols if a symbol-file has changed. */
void
reread_symbols (void)
@@ -2063,7 +2155,7 @@ reread_separate_symbols (struct objfile
Preserve the flags from objfile that make sense. */
objfile->separate_debug_objfile
= (symbol_file_add_with_addrs_or_offsets
- (debug_file,
+ (debug_file, NULL,
info_verbose, /* from_tty: Don't override the default. */
0, /* No addr table. */
objfile->section_offsets, objfile->num_sections,
@@ -3566,6 +3658,13 @@ with the text. SECT is a section name t
&cmdlist);
set_cmd_completer (c, filename_completer);
+ c = add_cmd ("add-symbol-file-from-memory", class_files,
+ add_symbol_file_from_memory_command,
+ "Usage: add-symbol-file-from-memory ADDR\n\
+Load the symbols out of memory from a dynamically loaded object file.\n\
+ADDR is the starting address of the file's shared object file header.",
+ &cmdlist);
+
c = add_cmd ("add-shared-symbol-files", class_files,
add_shared_symbol_files_command,
"Load the symbols from shared objects in the dynamic linker's link map.",
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [PATCH] add-symbol-file-from-memory command
2004-02-02 4:47 ` Roland McGrath
@ 2004-02-02 15:02 ` Daniel Jacobowitz
2004-02-02 23:31 ` Roland McGrath
0 siblings, 1 reply; 40+ messages in thread
From: Daniel Jacobowitz @ 2004-02-02 15:02 UTC (permalink / raw)
To: Roland McGrath; +Cc: gdb-patches
On Sun, Feb 01, 2004 at 08:47:41PM -0800, Roland McGrath wrote:
> > I can't approve this patch, but I have some comments anyway.
>
> Much appreciated.
>
> > There also was a segfault when the objfile is released. To reproduce,
> > I could just say "file\n" after loading one. GDB will try to
> > xfree("<in-memory>"). I see that this is fixed in the patch below, so
> > if the bits were unchanged from your last post then I must have come up
> > with the wrong copy.
>
> I won't testify to not having noticed and fixed (and since forgotten) some
> small bug like this between the last time I posted and today. Probably I did.
>
> > I can tell you one problem with this patch, based on my backport of it:
> > there's an annoying/incorrect message when a program is re-run, saying:
> > "<in-memory>" has disappeared; keeping its symbols
> >
> > This is merely an annoyance, the message is harmless but should be
> > fixed.
>
> I don't see this. AFAICT it just loses the symbols, like it should. What
> exactly is the recipe for seeing this? This may be something else I forgot
> I changed. It sets the OBJF_SHARED flag, which means the objfile is
> dropped by objfile_purge_solibs for "run".
Both of these are changes since the last time you posted the patch, so
please do not insist it was unchanged.
> > Mind doing this in some way that isn't gratuitously quadratic?
>
> Sure. I only used bfd_map_over_sections since it was said to be preferred.
Thanks.
> > Please remove the check and the !from_tty branch. An error is fine in
> > either case, and internal errors are not appropriate for user input.
> > Further down you have different error behavior on !from_tty also. Is
> > there a particular inspiration for this?
>
> My thinking was that when there are later internal calls to this function
> from target code, it would be an indication of a bug in the target code if
> it ever got called for a non-ELF target, and those would be the called with
> from_tty==0, hence the gdb_assert. The other errors indicate that the
> thing was reasonable to attempt, but failed. I think I copied the from_tty
> conditional for those errors from some other code I found similar, but I
> may be misremembering. I am more than happy to have you tell me a clear
> policy on what from_tty should or shouldn't affect.
from_tty should generally only affect verbosity. If the user puts
commands in a .gdbinit, they will be run with from_tty == 0, and should
still trigger an error () when necessary.
> > > + reinit_frame_cache (); /* ??? */
> >
> > Yes, this is necessary if the current cached backtrace would pass
> > through the newly loaded object.
>
> I appreciate the explanation. I've added a comment.
> I'm appending my current version of the symfile.c part of the patch.
> + 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);
> + if (from_tty)
> + error ("Got object file from memory but can't read symbols: %s.",
> + bfd_errmsg (bfd_get_error ()));
> + return NULL;
> + }
Same thing...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [PATCH] add-symbol-file-from-memory command
2004-02-02 15:02 ` Daniel Jacobowitz
@ 2004-02-02 23:31 ` Roland McGrath
2004-02-02 23:34 ` Daniel Jacobowitz
0 siblings, 1 reply; 40+ messages in thread
From: Roland McGrath @ 2004-02-02 23:31 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
> Both of these are changes since the last time you posted the patch, so
> please do not insist it was unchanged.
I already corrected that claim, and you quoted me doing so.
Claiming something once and then correcting it is "insisting"?
> from_tty should generally only affect verbosity. If the user puts
> commands in a .gdbinit, they will be run with from_tty == 0, and should
> still trigger an error () when necessary.
Gotcha.
> Same thing...
Right, I didn't touch those pending the directive that you have just given
me above, so I will now change them accordingly.
Thanks,
Roland
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2004-02-02 23:31 ` Roland McGrath
@ 2004-02-02 23:34 ` Daniel Jacobowitz
0 siblings, 0 replies; 40+ messages in thread
From: Daniel Jacobowitz @ 2004-02-02 23:34 UTC (permalink / raw)
To: Roland McGrath; +Cc: gdb-patches
On Mon, Feb 02, 2004 at 03:31:23PM -0800, Roland McGrath wrote:
> > Both of these are changes since the last time you posted the patch, so
> > please do not insist it was unchanged.
>
> I already corrected that claim, and you quoted me doing so.
> Claiming something once and then correcting it is "insisting"?
Sorry then.
> > from_tty should generally only affect verbosity. If the user puts
> > commands in a .gdbinit, they will be run with from_tty == 0, and should
> > still trigger an error () when necessary.
>
> Gotcha.
>
> > Same thing...
>
> Right, I didn't touch those pending the directive that you have just given
> me above, so I will now change them accordingly.
Thanks.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2004-02-02 3:38 Roland McGrath
2004-02-02 4:06 ` Daniel Jacobowitz
@ 2004-02-02 6:19 ` Eli Zaretskii
2004-02-02 7:35 ` Roland McGrath
1 sibling, 1 reply; 40+ messages in thread
From: Eli Zaretskii @ 2004-02-02 6:19 UTC (permalink / raw)
To: Roland McGrath; +Cc: gdb-patches
> Date: Sun, 1 Feb 2004 19:38:26 -0800
> From: Roland McGrath <roland@redhat.com>
>
> This patch hasn't changed since the last time I posted it. But I'm hoping
> that it will be approved this time. This support (the underlying function,
> not the user command) is the last nontrivial piece required for backtraces
> from system calls to work right with vanilla Linux 2.6 kernels. The only
> objections previously were not apropos, and noone said anything about the
> content of the code itself. If there is valid cause not to put this in
> now, I hope I can see it stated clearly.
I have a couple of minor comments regarding the documentation and the
user interface:
> + c = add_cmd ("add-symbol-file-from-memory", class_files,
> + add_symbol_file_from_memory_command,
> + "Usage: add-symbol-file-from-memory ADDR\n\
> +Load the symbols out of memory from a dynamically loaded object file.\n\
> +ADDR is the starting address of the file's shared object file header.",
> + &cmdlist);
> +
There are two problems with this command definition:
. The first line of the doc string, up until the first \n, should
be a short description of the command, since that is what GDB
displays when several commands are listed (e.g., by `apropos' or
`help files' commands). [Yes, I know: `add-symbol-file' that is
already there has the same problem.]
. It is not entirely clear what could ADDR be. Is that a numerical
address, or something more flexible? The reason that this is
important is that the command's completion function should be set
according to the possible arguments it could accept; as written,
the command's completion will try to complete on symbol names,
which I'm not sure to be appropriate.
Also, if this code is approved, please add to the manual a
description of the new command.
TIA
P.S. This command is undocumented. Could someone of the symfile.c
maintainers please document it?
> c = add_cmd ("add-shared-symbol-files", class_files,
> add_shared_symbol_files_command,
> "Load the symbols from shared objects in the dynamic linker's link map.",
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [PATCH] add-symbol-file-from-memory command
2004-02-02 6:19 ` Eli Zaretskii
@ 2004-02-02 7:35 ` Roland McGrath
2004-02-02 17:29 ` Eli Zaretskii
0 siblings, 1 reply; 40+ messages in thread
From: Roland McGrath @ 2004-02-02 7:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb-patches
> . The first line of the doc string, up until the first \n, should
> be a short description of the command, since that is what GDB
> displays when several commands are listed (e.g., by `apropos' or
> `help files' commands). [Yes, I know: `add-symbol-file' that is
> already there has the same problem.]
Ok. I used add-symbol-file as the model. How about this text?
"Load the symbols out of memory from a dynamically loaded object file.\n\
Specify an expression for the address of the file's shared object file header."
> . It is not entirely clear what could ADDR be. Is that a numerical
> address, or something more flexible? The reason that this is
> important is that the command's completion function should be set
> according to the possible arguments it could accept; as written,
> the command's completion will try to complete on symbol names,
> which I'm not sure to be appropriate.
It uses `parse_and_eval_address', again modelled on the add-symbol-file
command's implementation. I think that makes generic completion, including
symbol names or whatever, the appropriate thing.
> Also, if this code is approved, please add to the manual a
> description of the new command.
Ok.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2004-02-02 7:35 ` Roland McGrath
@ 2004-02-02 17:29 ` Eli Zaretskii
0 siblings, 0 replies; 40+ messages in thread
From: Eli Zaretskii @ 2004-02-02 17:29 UTC (permalink / raw)
To: Roland McGrath; +Cc: gdb-patches
> Date: Sun, 1 Feb 2004 23:35:35 -0800
> From: Roland McGrath <roland@redhat.com>
>
> > . The first line of the doc string, up until the first \n, should
> > be a short description of the command, since that is what GDB
> > displays when several commands are listed (e.g., by `apropos' or
> > `help files' commands). [Yes, I know: `add-symbol-file' that is
> > already there has the same problem.]
>
> Ok. I used add-symbol-file as the model. How about this text?
>
> "Load the symbols out of memory from a dynamically loaded object file.\n\
> Specify an expression for the address of the file's shared object file header."
Looks good to me, thanks.
^ permalink raw reply [flat|nested] 40+ messages in thread
* [PATCH] add-symbol-file-from-memory command
@ 2004-02-12 0:34 Roland McGrath
2004-02-13 15:54 ` Andrew Cagney
0 siblings, 1 reply; 40+ messages in thread
From: Roland McGrath @ 2004-02-12 0:34 UTC (permalink / raw)
To: gdb-patches
I've cleaned up some nits that Daniel pointed out. This is the current
version of my add-symbol-file-from-memory patch. I've tested it and it
works with today's mainline gdb. Are there any remaining problems people
see with this code? Can it go in?
Thanks,
Roland
2004-02-11 Roland McGrath <roland@redhat.com>
* symfile.c (symbol_file_add_with_addrs_or_offsets): Take ABFD as
a new argument. Call symfile_bfd_open only if passed a null pointer.
(symbol_file_add, reread_separate_symbols): Update callers.
(build_addr_info): New function, helper for ...
(symbol_file_add_from_memory): New function.
(add_symbol_file_from_memory_command): New function using that.
(_initialize_symfile): Register it for add-symbol-file-from-memory.
* symfile.h (symbol_file_add_from_memory): Declare it.
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.121
diff -p -u -r1.121 symfile.c
--- symfile.c 9 Feb 2004 23:50:55 -0000 1.121
+++ symfile.c 11 Feb 2004 21:02:31 -0000
@@ -799,6 +799,10 @@ new_symfile_objfile (struct objfile *obj
NAME is the file name (which will be tilde-expanded and made
absolute herein) (but we don't free or modify NAME itself).
+ If ABFD is not null, it's already open and should be used instead of
+ opening the file by name. This BFD will be closed on error, and
+ is always consumed by this function.
+
FROM_TTY says how verbose to be.
MAINLINE specifies whether this is the main symbol file, or whether
@@ -811,7 +815,7 @@ new_symfile_objfile (struct objfile *obj
Upon success, returns a pointer to the objfile that was added.
Upon failure, jumps back to command level (never returns). */
static struct objfile *
-symbol_file_add_with_addrs_or_offsets (char *name, int from_tty,
+symbol_file_add_with_addrs_or_offsets (char *name, bfd *abfd, int from_tty,
struct section_addr_info *addrs,
struct section_offsets *offsets,
int num_offsets,
@@ -820,14 +824,16 @@ symbol_file_add_with_addrs_or_offsets (c
struct objfile *objfile;
struct partial_symtab *psymtab;
char *debugfile;
- bfd *abfd;
struct section_addr_info *orig_addrs;
struct cleanup *my_cleanups;
/* Open a bfd for the file, and give user a chance to burp if we'd be
interactively wiping out any existing symbols. */
- abfd = symfile_bfd_open (name);
+ if (abfd == NULL)
+ abfd = symfile_bfd_open (name);
+
+ my_cleanups = make_cleanup_bfd_close (abfd);
if ((have_full_symbols () || have_partial_symbols ())
&& mainline
@@ -836,6 +842,7 @@ symbol_file_add_with_addrs_or_offsets (c
error ("Not confirmed.");
objfile = allocate_objfile (abfd, flags);
+ discard_cleanups (my_cleanups);
orig_addrs = alloc_section_addr_info (bfd_count_sections (abfd));
my_cleanups = make_cleanup (xfree, orig_addrs);
@@ -952,7 +959,8 @@ struct objfile *
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 (name, from_tty, addrs, 0, 0,
+ return symbol_file_add_with_addrs_or_offsets (name, NULL, from_tty,
+ addrs, 0, 0,
mainline, flags);
}
@@ -1802,6 +1810,88 @@ add_shared_symbol_files_command (char *a
#endif
}
\f
+/* 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 ((char *) nbfd->filename, nbfd,
+ from_tty, sai, NULL, 0, 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.");
+
+ (void) symbol_file_add_from_memory (templ, addr, from_tty);
+}
+\f
/* Re-read symbols if a symbol-file has changed. */
void
reread_symbols (void)
@@ -3561,6 +3651,13 @@ with the text. SECT is a section name t
&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,
"Load the symbols from shared objects in the dynamic linker's link map.",
Index: symfile.h
===================================================================
RCS file: /cvs/src/src/gdb/symfile.h,v
retrieving revision 1.26
diff -p -u -r1.26 symfile.h
--- symfile.h 7 Feb 2004 23:13:47 -0000 1.26
+++ symfile.h 11 Feb 2004 21:02:31 -0000
@@ -306,6 +306,12 @@ extern CORE_ADDR symbol_overlayed_addres
/* Load symbols from a file. */
extern void symbol_file_add_main (char *args, int from_tty);
+/* 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. */
+extern struct objfile *symbol_file_add_from_memory (bfd *templ, CORE_ADDR addr,
+ int from_tty);
+
/* Clear GDB symbol tables. */
extern void symbol_file_clear (int from_tty);
^ permalink raw reply [flat|nested] 40+ messages in thread* [PATCH] add-symbol-file-from-memory command
@ 2004-04-08 20:47 Roland McGrath
2004-04-08 22:13 ` Jim Blandy
0 siblings, 1 reply; 40+ messages in thread
From: Roland McGrath @ 2004-04-08 20:47 UTC (permalink / raw)
To: gdb-patches
I updated my tree and made a new diff for add-symbol-file-from-memory,
though there were no conflicts to resolve so it's not materially different
from the last version of this patch I posted. It still works with today's
gdb. Several people have looked at this code before. It just needs
authoritative approval to go in. If anyone has any reservations, I haven't
heard them articulated. As I've mentioned before, the new command itself
is not the motivation for the new function. It's the final piece of
necessary infrastructure for vsyscall DSO support for Linux targets.
(After this, the only thing needed is the glue to check for AT_SYSINFO at
the right time.)
Thanks,
Roland
Index: gdb/symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.124
diff -p -u -r1.124 symfile.c
--- gdb/symfile.c 28 Feb 2004 18:04:37 -0000 1.124
+++ gdb/symfile.c 8 Apr 2004 20:31:27 -0000
@@ -764,6 +764,10 @@ new_symfile_objfile (struct objfile *obj
NAME is the file name (which will be tilde-expanded and made
absolute herein) (but we don't free or modify NAME itself).
+ If ABFD is not null, it's already open and should be used instead of
+ opening the file by name. This BFD will be closed on error, and
+ is always consumed by this function.
+
FROM_TTY says how verbose to be.
MAINLINE specifies whether this is the main symbol file, or whether
@@ -776,7 +780,7 @@ new_symfile_objfile (struct objfile *obj
Upon success, returns a pointer to the objfile that was added.
Upon failure, jumps back to command level (never returns). */
static struct objfile *
-symbol_file_add_with_addrs_or_offsets (char *name, int from_tty,
+symbol_file_add_with_addrs_or_offsets (char *name, bfd *abfd, int from_tty,
struct section_addr_info *addrs,
struct section_offsets *offsets,
int num_offsets,
@@ -785,14 +789,16 @@ symbol_file_add_with_addrs_or_offsets (c
struct objfile *objfile;
struct partial_symtab *psymtab;
char *debugfile;
- bfd *abfd;
struct section_addr_info *orig_addrs;
struct cleanup *my_cleanups;
/* Open a bfd for the file, and give user a chance to burp if we'd be
interactively wiping out any existing symbols. */
- abfd = symfile_bfd_open (name);
+ if (abfd == NULL)
+ abfd = symfile_bfd_open (name);
+
+ my_cleanups = make_cleanup_bfd_close (abfd);
if ((have_full_symbols () || have_partial_symbols ())
&& mainline
@@ -801,6 +807,7 @@ symbol_file_add_with_addrs_or_offsets (c
error ("Not confirmed.");
objfile = allocate_objfile (abfd, flags);
+ discard_cleanups (my_cleanups);
orig_addrs = alloc_section_addr_info (bfd_count_sections (abfd));
my_cleanups = make_cleanup (xfree, orig_addrs);
@@ -917,7 +924,8 @@ struct objfile *
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 (name, from_tty, addrs, 0, 0,
+ return symbol_file_add_with_addrs_or_offsets (name, NULL, from_tty,
+ addrs, 0, 0,
mainline, flags);
}
@@ -1767,6 +1775,88 @@ add_shared_symbol_files_command (char *a
#endif
}
\f
+/* 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 ((char *) nbfd->filename, nbfd,
+ from_tty, sai, NULL, 0, 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.");
+
+ (void) symbol_file_add_from_memory (templ, addr, from_tty);
+}
+\f
/* Re-read symbols if a symbol-file has changed. */
void
reread_symbols (void)
@@ -2023,7 +2113,7 @@ reread_separate_symbols (struct objfile
Preserve the flags from objfile that make sense. */
objfile->separate_debug_objfile
= (symbol_file_add_with_addrs_or_offsets
- (debug_file,
+ (debug_file, NULL,
info_verbose, /* from_tty: Don't override the default. */
0, /* No addr table. */
objfile->section_offsets, objfile->num_sections,
@@ -3526,6 +3616,13 @@ with the text. SECT is a section name t
&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,
"Load the symbols from shared objects in the dynamic linker's link map.",
Index: gdb/symfile.h
===================================================================
RCS file: /cvs/src/src/gdb/symfile.h,v
retrieving revision 1.28
diff -p -u -r1.28 symfile.h
--- gdb/symfile.h 2 Apr 2004 19:23:05 -0000 1.28
+++ gdb/symfile.h 8 Apr 2004 20:31:27 -0000
@@ -302,6 +302,12 @@ extern CORE_ADDR symbol_overlayed_addres
/* Load symbols from a file. */
extern void symbol_file_add_main (char *args, int from_tty);
+/* 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. */
+extern struct objfile *symbol_file_add_from_memory (bfd *templ, CORE_ADDR addr,
+ int from_tty);
+
/* Clear GDB symbol tables. */
extern void symbol_file_clear (int from_tty);
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [PATCH] add-symbol-file-from-memory command
2004-04-08 20:47 Roland McGrath
@ 2004-04-08 22:13 ` Jim Blandy
2004-04-08 22:28 ` Roland McGrath
2004-04-08 22:35 ` Andrew Cagney
0 siblings, 2 replies; 40+ messages in thread
From: Jim Blandy @ 2004-04-08 22:13 UTC (permalink / raw)
To: Roland McGrath; +Cc: gdb-patches
Roland McGrath <roland@redhat.com> writes:
> I updated my tree and made a new diff for add-symbol-file-from-memory,
> though there were no conflicts to resolve so it's not materially different
> >From the last version of this patch I posted. It still works with today's
> gdb. Several people have looked at this code before. It just needs
> authoritative approval to go in. If anyone has any reservations, I haven't
> heard them articulated. As I've mentioned before, the new command itself
> is not the motivation for the new function. It's the final piece of
> necessary infrastructure for vsyscall DSO support for Linux targets.
> (After this, the only thing needed is the glue to check for AT_SYSINFO at
> the right time.)
This looks fine. Two suggestions:
- Would it work to completely replace
symbol_file_add_with_addrs_or_offsets's 'name' argument with the
abfd argument, and then just use bfd_get_filename? It looks to me
like the only affect would be that the tilde-expanded, path-searched
filename would appear in messages, which seems like a good thing.
- Since the command isn't something that ordinary users are really
going to want themselves, but is more for the benefit of GDB
developers, should be a 'maint' subcommand?
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2004-04-08 22:13 ` Jim Blandy
@ 2004-04-08 22:28 ` Roland McGrath
2004-04-08 22:32 ` Daniel Jacobowitz
2004-04-08 22:35 ` Andrew Cagney
1 sibling, 1 reply; 40+ messages in thread
From: Roland McGrath @ 2004-04-08 22:28 UTC (permalink / raw)
To: Jim Blandy; +Cc: gdb-patches
> - Would it work to completely replace
> symbol_file_add_with_addrs_or_offsets's 'name' argument with the
> abfd argument, and then just use bfd_get_filename? It looks to me
> like the only affect would be that the tilde-expanded, path-searched
> filename would appear in messages, which seems like a good thing.
I don't see any problem with this. I intentionally did not perturb other
callers, but it would be a simple change to have them call symfile_bfd_open
in their args.
> - Since the command isn't something that ordinary users are really
> going to want themselves, but is more for the benefit of GDB
> developers, should be a 'maint' subcommand?
I think it's in the same category of usefulness as add-symbol-file.
Thanks,
Roland
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2004-04-08 22:28 ` Roland McGrath
@ 2004-04-08 22:32 ` Daniel Jacobowitz
0 siblings, 0 replies; 40+ messages in thread
From: Daniel Jacobowitz @ 2004-04-08 22:32 UTC (permalink / raw)
To: Roland McGrath; +Cc: Jim Blandy, gdb-patches
On Thu, Apr 08, 2004 at 03:27:58PM -0700, Roland McGrath wrote:
> > - Would it work to completely replace
> > symbol_file_add_with_addrs_or_offsets's 'name' argument with the
> > abfd argument, and then just use bfd_get_filename? It looks to me
> > like the only affect would be that the tilde-expanded, path-searched
> > filename would appear in messages, which seems like a good thing.
>
> I don't see any problem with this. I intentionally did not perturb other
> callers, but it would be a simple change to have them call symfile_bfd_open
> in their args.
I like Jim's suggestion, since the wrong error messages have really
bugged me. OTOH, this won't fix all of them - "name" is still used in
symfile_bfd_open to print some errors. But progress...
> > - Since the command isn't something that ordinary users are really
> > going to want themselves, but is more for the benefit of GDB
> > developers, should be a 'maint' subcommand?
>
> I think it's in the same category of usefulness as add-symbol-file.
Me, too.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2004-04-08 22:13 ` Jim Blandy
2004-04-08 22:28 ` Roland McGrath
@ 2004-04-08 22:35 ` Andrew Cagney
2004-04-08 22:42 ` Roland McGrath
1 sibling, 1 reply; 40+ messages in thread
From: Andrew Cagney @ 2004-04-08 22:35 UTC (permalink / raw)
To: Roland McGrath; +Cc: gdb-patches
> + nbfd = bfd_elf_bfd_from_remote_memory (templ, addr, &loadbase,
> + target_read_memory);
Roland, FYI,
This is another of those bits of infrastructure that someone dropped.
With 6.1 out (I can't yet announce it) I'm picking it up and sorting it out.
So the interface might change slightly but not by much.
Andrew
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2004-04-08 22:35 ` Andrew Cagney
@ 2004-04-08 22:42 ` Roland McGrath
2004-04-15 18:52 ` Andrew Cagney
0 siblings, 1 reply; 40+ messages in thread
From: Roland McGrath @ 2004-04-08 22:42 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb-patches
> > + nbfd = bfd_elf_bfd_from_remote_memory (templ, addr, &loadbase,
> > + target_read_memory);
>
> Roland, FYI,
>
> This is another of those bits of infrastructure that someone dropped.
> With 6.1 out (I can't yet announce it) I'm picking it up and sorting it out.
>
> So the interface might change slightly but not by much.
Can you be specific? The bfd_elf_bfd_from_remote_memory code in BFD now
works just fine. There is a standing suggestion from Jim to change the
signature of the TARGET_READ_MEMORY function pointer argument, which is
certainly fine (and two minutes' work). I would be happy to prepare that
change right away if it's what people want.
I don't know of any other way in which this might be considered "dropped"
or "not sorted out". If there is anything else you have in mind, please
tell me about it.
Thanks,
Roland
^ permalink raw reply [flat|nested] 40+ messages in thread
* [PATCH] add-symbol-file-from-memory command
@ 2004-04-08 22:38 Roland McGrath
2004-04-15 18:11 ` Jim Blandy
0 siblings, 1 reply; 40+ messages in thread
From: Roland McGrath @ 2004-04-08 22:38 UTC (permalink / raw)
To: gdb-patches
This is a version of the patch with the internal function's calling
convention changed as Jim suggested.
Thanks,
Roland
ChangeLog:
2004-04-08 Roland McGrath <roland@redhat.com>
* symfile.c (symbol_file_add_with_addrs_or_offsets): Take ABFD as
argument instead of NAME.
(symbol_file_add, reread_separate_symbols): Call symfile_bfd_open
in call to symbol_file_add_with_addrs_or_offsets.
(build_addr_info): New function, helper for ...
(symbol_file_add_from_memory): New function.
(add_symbol_file_from_memory_command): New function using that.
(_initialize_symfile): Register it for add-symbol-file-from-memory.
(pre_add_symbol_hook): Add const to argument type.
* symfile.h (symbol_file_add_from_memory): Declare it.
gdbtk/ChangeLog:
2004-04-08 Roland McGrath <roland@redhat.com>
* generic/gdbtk-hooks.c (gdbtk_pre_add_symbol): Add const to arg type.
(pre_add_symbol): Likewise in extern decl.
Index: gdb/symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.124
diff -b -p -u -r1.124 symfile.c
--- gdb/symfile.c 28 Feb 2004 18:04:37 -0000 1.124
+++ gdb/symfile.c 8 Apr 2004 22:35:02 -0000
@@ -79,7 +79,7 @@ void (*show_load_progress) (const char *
unsigned long section_size,
unsigned long total_sent,
unsigned long total_size);
-void (*pre_add_symbol_hook) (char *);
+void (*pre_add_symbol_hook) (const char *);
void (*post_add_symbol_hook) (void);
void (*target_new_objfile_hook) (struct objfile *);
@@ -761,8 +761,8 @@ new_symfile_objfile (struct objfile *obj
/* Process a symbol file, as either the main file or as a dynamically
loaded file.
- NAME is the file name (which will be tilde-expanded and made
- absolute herein) (but we don't free or modify NAME itself).
+ ABFD is a BFD already open on the file, as from symfile_bfd_open.
+ This BFD will be closed on error, and is always consumed by this function.
FROM_TTY says how verbose to be.
@@ -776,7 +776,7 @@ new_symfile_objfile (struct objfile *obj
Upon success, returns a pointer to the objfile that was added.
Upon failure, jumps back to command level (never returns). */
static struct objfile *
-symbol_file_add_with_addrs_or_offsets (char *name, int from_tty,
+symbol_file_add_with_addrs_or_offsets (bfd *abfd, int from_tty,
struct section_addr_info *addrs,
struct section_offsets *offsets,
int num_offsets,
@@ -785,14 +785,14 @@ symbol_file_add_with_addrs_or_offsets (c
struct objfile *objfile;
struct partial_symtab *psymtab;
char *debugfile;
- bfd *abfd;
struct section_addr_info *orig_addrs;
struct cleanup *my_cleanups;
+ const char *name = bfd_get_filename (abfd);
- /* Open a bfd for the file, and give user a chance to burp if we'd be
- interactively wiping out any existing symbols. */
+ my_cleanups = make_cleanup_bfd_close (abfd);
- abfd = symfile_bfd_open (name);
+ /* Give user a chance to burp if we'd be
+ interactively wiping out any existing symbols. */
if ((have_full_symbols () || have_partial_symbols ())
&& mainline
@@ -801,6 +801,7 @@ symbol_file_add_with_addrs_or_offsets (c
error ("Not confirmed.");
objfile = allocate_objfile (abfd, flags);
+ discard_cleanups (my_cleanups);
orig_addrs = alloc_section_addr_info (bfd_count_sections (abfd));
my_cleanups = make_cleanup (xfree, orig_addrs);
@@ -917,7 +918,8 @@ struct objfile *
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 (name, from_tty, addrs, 0, 0,
+ return symbol_file_add_with_addrs_or_offsets (symfile_bfd_open (name),
+ from_tty, addrs, 0, 0,
mainline, flags);
}
@@ -1767,6 +1769,87 @@ add_shared_symbol_files_command (char *a
#endif
}
\f
+/* 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;
+}
+
+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.");
+
+ (void) symbol_file_add_from_memory (templ, addr, from_tty);
+}
+\f
/* Re-read symbols if a symbol-file has changed. */
void
reread_symbols (void)
@@ -2023,7 +2106,7 @@ reread_separate_symbols (struct objfile
Preserve the flags from objfile that make sense. */
objfile->separate_debug_objfile
= (symbol_file_add_with_addrs_or_offsets
- (debug_file,
+ (symfile_bfd_open (debug_file),
info_verbose, /* from_tty: Don't override the default. */
0, /* No addr table. */
objfile->section_offsets, objfile->num_sections,
@@ -3526,6 +3609,13 @@ with the text. SECT is a section name t
&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,
"Load the symbols from shared objects in the dynamic linker's link map.",
Index: gdb/symfile.h
===================================================================
RCS file: /cvs/src/src/gdb/symfile.h,v
retrieving revision 1.28
diff -b -p -u -r1.28 symfile.h
--- gdb/symfile.h 2 Apr 2004 19:23:05 -0000 1.28
+++ gdb/symfile.h 8 Apr 2004 22:35:02 -0000
@@ -302,6 +302,12 @@ extern CORE_ADDR symbol_overlayed_addres
/* Load symbols from a file. */
extern void symbol_file_add_main (char *args, int from_tty);
+/* 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. */
+extern struct objfile *symbol_file_add_from_memory (bfd *templ, CORE_ADDR addr,
+ int from_tty);
+
/* Clear GDB symbol tables. */
extern void symbol_file_clear (int from_tty);
Index: gdb/gdbtk/generic/gdbtk-hooks.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-hooks.c,v
retrieving revision 1.31
diff -b -p -u -r1.31 gdbtk-hooks.c
--- gdb/gdbtk/generic/gdbtk-hooks.c 12 Feb 2003 16:02:03 -0000 1.31
+++ gdb/gdbtk/generic/gdbtk-hooks.c 8 Apr 2004 22:35:11 -0000
@@ -73,7 +73,7 @@ extern void gdbtk_create_tracepoint (int
extern void gdbtk_delete_tracepoint (int);
extern void gdbtk_modify_tracepoint (int);
-extern void (*pre_add_symbol_hook) (char *);
+extern void (*pre_add_symbol_hook) (const char *);
extern void (*post_add_symbol_hook) (void);
extern void (*selected_frame_level_changed_hook) (int);
extern int (*ui_loop_hook) (int);
@@ -599,7 +599,7 @@ gdbtk_load_hash (const char *section, un
/* This hook is called whenever we are ready to load a symbol file so that
the UI can notify the user... */
static void
-gdbtk_pre_add_symbol (char *name)
+gdbtk_pre_add_symbol (const char *name)
{
gdbtk_two_elem_cmd ("gdbtk_tcl_pre_add_symbol", name);
}
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [PATCH] add-symbol-file-from-memory command
2004-04-08 22:38 Roland McGrath
@ 2004-04-15 18:11 ` Jim Blandy
2004-04-15 18:49 ` Andrew Cagney
2004-04-15 21:42 ` Roland McGrath
0 siblings, 2 replies; 40+ messages in thread
From: Jim Blandy @ 2004-04-15 18:11 UTC (permalink / raw)
To: Roland McGrath; +Cc: gdb-patches
Roland McGrath <roland@redhat.com> writes:
> This is a version of the patch with the internal function's calling
> convention changed as Jim suggested.
This looks fine. If neither you nor Daniel feel it should be a
'maint' command, that's okay. Please commit.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2004-04-15 18:11 ` Jim Blandy
@ 2004-04-15 18:49 ` Andrew Cagney
2004-04-15 21:42 ` Roland McGrath
1 sibling, 0 replies; 40+ messages in thread
From: Andrew Cagney @ 2004-04-15 18:49 UTC (permalink / raw)
To: Jim Blandy; +Cc: Roland McGrath, gdb-patches
> Roland McGrath <roland@redhat.com> writes:
>
>>> This is a version of the patch with the internal function's calling
>>> convention changed as Jim suggested.
>
>
> This looks fine. If neither you nor Daniel feel it should be a
> 'maint' command, that's okay. Please commit.
FYI, this isn't a maint command. While wierd, its use by a normal user
is reasonable. Did this get documented?
Andrew
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] add-symbol-file-from-memory command
2004-04-15 18:11 ` Jim Blandy
2004-04-15 18:49 ` Andrew Cagney
@ 2004-04-15 21:42 ` Roland McGrath
1 sibling, 0 replies; 40+ messages in thread
From: Roland McGrath @ 2004-04-15 21:42 UTC (permalink / raw)
To: gdb-patches
> This looks fine. If neither you nor Daniel feel it should be a
> 'maint' command, that's okay. Please commit.
Committed, and here it is again (unchanged but for a little merging).
2004-04-15 Roland McGrath <roland@redhat.com>
* symfile.c (symbol_file_add_with_addrs_or_offsets): Take ABFD as
argument instead of NAME.
(symbol_file_add, reread_separate_symbols): Call symfile_bfd_open
in call to symbol_file_add_with_addrs_or_offsets.
(build_addr_info): New function, helper for ...
(symbol_file_add_from_memory): New function.
(add_symbol_file_from_memory_command): New function using that.
(_initialize_symfile): Register it for add-symbol-file-from-memory.
(pre_add_symbol_hook): Add const to argument type.
* symfile.h (symbol_file_add_from_memory): Declare it.
gdbtk/
2004-04-15 Roland McGrath <roland@redhat.com>
* generic/gdbtk-hooks.c (gdbtk_pre_add_symbol): Add const to arg type.
(pre_add_symbol): Likewise in extern decl.
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.125
retrieving revision 1.126
diff -b -p -u -r1.125 -r1.126
--- symfile.c 8 Apr 2004 21:18:13 -0000 1.125
+++ symfile.c 15 Apr 2004 21:39:27 -0000 1.126
@@ -78,7 +78,7 @@ void (*show_load_progress) (const char *
unsigned long section_size,
unsigned long total_sent,
unsigned long total_size);
-void (*pre_add_symbol_hook) (char *);
+void (*pre_add_symbol_hook) (const char *);
void (*post_add_symbol_hook) (void);
void (*target_new_objfile_hook) (struct objfile *);
@@ -760,8 +760,8 @@ new_symfile_objfile (struct objfile *obj
/* Process a symbol file, as either the main file or as a dynamically
loaded file.
- NAME is the file name (which will be tilde-expanded and made
- absolute herein) (but we don't free or modify NAME itself).
+ ABFD is a BFD already open on the file, as from symfile_bfd_open.
+ This BFD will be closed on error, and is always consumed by this function.
FROM_TTY says how verbose to be.
@@ -775,7 +775,7 @@ new_symfile_objfile (struct objfile *obj
Upon success, returns a pointer to the objfile that was added.
Upon failure, jumps back to command level (never returns). */
static struct objfile *
-symbol_file_add_with_addrs_or_offsets (char *name, int from_tty,
+symbol_file_add_with_addrs_or_offsets (bfd *abfd, int from_tty,
struct section_addr_info *addrs,
struct section_offsets *offsets,
int num_offsets,
@@ -784,14 +784,14 @@ symbol_file_add_with_addrs_or_offsets (c
struct objfile *objfile;
struct partial_symtab *psymtab;
char *debugfile;
- bfd *abfd;
struct section_addr_info *orig_addrs;
struct cleanup *my_cleanups;
+ const char *name = bfd_get_filename (abfd);
- /* Open a bfd for the file, and give user a chance to burp if we'd be
- interactively wiping out any existing symbols. */
+ my_cleanups = make_cleanup_bfd_close (abfd);
- abfd = symfile_bfd_open (name);
+ /* Give user a chance to burp if we'd be
+ interactively wiping out any existing symbols. */
if ((have_full_symbols () || have_partial_symbols ())
&& mainline
@@ -800,6 +800,7 @@ symbol_file_add_with_addrs_or_offsets (c
error ("Not confirmed.");
objfile = allocate_objfile (abfd, flags);
+ discard_cleanups (my_cleanups);
orig_addrs = alloc_section_addr_info (bfd_count_sections (abfd));
my_cleanups = make_cleanup (xfree, orig_addrs);
@@ -916,7 +917,8 @@ struct objfile *
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 (name, from_tty, addrs, 0, 0,
+ return symbol_file_add_with_addrs_or_offsets (symfile_bfd_open (name),
+ from_tty, addrs, 0, 0,
mainline, flags);
}
@@ -1766,6 +1768,87 @@ add_shared_symbol_files_command (char *a
#endif
}
\f
+/* 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;
+}
+
+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.");
+
+ (void) symbol_file_add_from_memory (templ, addr, from_tty);
+}
+\f
/* Re-read symbols if a symbol-file has changed. */
void
reread_symbols (void)
@@ -2022,7 +2105,7 @@ reread_separate_symbols (struct objfile
Preserve the flags from objfile that make sense. */
objfile->separate_debug_objfile
= (symbol_file_add_with_addrs_or_offsets
- (debug_file,
+ (symfile_bfd_open (debug_file),
info_verbose, /* from_tty: Don't override the default. */
0, /* No addr table. */
objfile->section_offsets, objfile->num_sections,
@@ -3525,6 +3608,13 @@ with the text. SECT is a section name t
&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,
"Load the symbols from shared objects in the dynamic linker's link map.",
Index: symfile.h
===================================================================
RCS file: /cvs/src/src/gdb/symfile.h,v
retrieving revision 1.28
retrieving revision 1.29
diff -b -p -u -r1.28 -r1.29
--- symfile.h 2 Apr 2004 19:23:05 -0000 1.28
+++ symfile.h 15 Apr 2004 21:39:27 -0000 1.29
@@ -302,6 +302,12 @@ extern CORE_ADDR symbol_overlayed_addres
/* Load symbols from a file. */
extern void symbol_file_add_main (char *args, int from_tty);
+/* 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. */
+extern struct objfile *symbol_file_add_from_memory (bfd *templ, CORE_ADDR addr,
+ int from_tty);
+
/* Clear GDB symbol tables. */
extern void symbol_file_clear (int from_tty);
Index: gdbtk/generic/gdbtk-hooks.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-hooks.c,v
retrieving revision 1.31
retrieving revision 1.32
diff -b -p -u -r1.31 -r1.32
--- gdbtk/generic/gdbtk-hooks.c 12 Feb 2003 16:02:03 -0000 1.31
+++ gdbtk/generic/gdbtk-hooks.c 15 Apr 2004 21:39:35 -0000 1.32
@@ -73,7 +73,7 @@ extern void gdbtk_create_tracepoint (int
extern void gdbtk_delete_tracepoint (int);
extern void gdbtk_modify_tracepoint (int);
-extern void (*pre_add_symbol_hook) (char *);
+extern void (*pre_add_symbol_hook) (const char *);
extern void (*post_add_symbol_hook) (void);
extern void (*selected_frame_level_changed_hook) (int);
extern int (*ui_loop_hook) (int);
@@ -599,7 +599,7 @@ gdbtk_load_hash (const char *section, un
/* This hook is called whenever we are ready to load a symbol file so that
the UI can notify the user... */
static void
-gdbtk_pre_add_symbol (char *name)
+gdbtk_pre_add_symbol (const char *name)
{
gdbtk_two_elem_cmd ("gdbtk_tcl_pre_add_symbol", name);
}
^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2004-04-15 21:42 UTC | newest]
Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-20 7:01 [PATCH] add-symbol-file-from-memory command Roland McGrath
2003-10-03 4:27 Roland McGrath
2003-10-03 21:41 ` Jim Blandy
2003-10-03 21:45 ` Daniel Jacobowitz
2003-10-03 22:08 ` Roland McGrath
2003-10-03 22:19 ` Elena Zannoni
2003-10-03 23:00 ` Roland McGrath
2003-10-04 12:57 ` Elena Zannoni
2003-10-04 20:14 ` Roland McGrath
2003-10-07 1:42 ` Andrew Cagney
2003-10-03 22:34 ` Andrew Cagney
2003-10-03 23:02 ` Roland McGrath
2003-10-04 14:39 ` Andrew Cagney
2003-10-06 15:30 ` Jim Blandy
2003-10-06 15:43 ` Daniel Jacobowitz
2003-10-06 19:57 ` Roland McGrath
2003-10-07 23:32 ` Michael Snyder
2004-02-02 3:38 Roland McGrath
2004-02-02 4:06 ` Daniel Jacobowitz
2004-02-02 4:47 ` Roland McGrath
2004-02-02 15:02 ` Daniel Jacobowitz
2004-02-02 23:31 ` Roland McGrath
2004-02-02 23:34 ` Daniel Jacobowitz
2004-02-02 6:19 ` Eli Zaretskii
2004-02-02 7:35 ` Roland McGrath
2004-02-02 17:29 ` Eli Zaretskii
2004-02-12 0:34 Roland McGrath
2004-02-13 15:54 ` Andrew Cagney
2004-02-13 19:13 ` Roland McGrath
2004-04-08 20:47 Roland McGrath
2004-04-08 22:13 ` Jim Blandy
2004-04-08 22:28 ` Roland McGrath
2004-04-08 22:32 ` Daniel Jacobowitz
2004-04-08 22:35 ` Andrew Cagney
2004-04-08 22:42 ` Roland McGrath
2004-04-15 18:52 ` Andrew Cagney
2004-04-08 22:38 Roland McGrath
2004-04-15 18:11 ` Jim Blandy
2004-04-15 18:49 ` Andrew Cagney
2004-04-15 21:42 ` Roland McGrath
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox