This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdbserver, sysroot, prelink


Daniel Jacobowitz <drow@false.org>:
> How does this make --with-sysroot useless?  That's exactly what sysroot
> is supposed to do - point it where you keep the exact libraries of the
> machine.  I usually point it to an NFS server.

doesn't that assume you only have one such target machine in your
installation?  in most setups I can think of, the sysroot symlink
has to be created by hand by the end-user of gdb, since he's the
one who decides what remote machine he's using.  I can't think
of a reasonable way for a packager or an installer to create a
default sysroot, since there's no place to tell gdb to use a
default remote machine.  so the gdb user might as well set
solib-absolute-prefix in his gdbinit, since that doesn't require
installation privs.

this problem is specific to gdb.  gcc doesn't care about the
prelink mangling, so for gcc purposes it's fine to use a generic
sysroot for the target.

this problem creates mysterious errors in gdb.  if you don't
supply the shared libs for the specific remote machine you're
using, gdb will appear to work, but it will fail to do some
things correctly, and there's no simple way of finding out what
the problem is if you don't already know the answer.

two example mysterious errors:
  'break printf' fails with a message like 'Can't access memory
    at address ...'
  'print "hi"' segfaults in a strange location.

maybe setting the default solib-absolute-prefix to something like
'[[please set solib-absolute-prefix]]' would be helpful when
there isn't a sensible default.
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]