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

[Daniel Jacobowitz <drow at mvista dot com>]

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