Re: [PATCH] add-symbol-file-from-memory command

[Jim Blandy <jimb@redhat.com>]

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.