Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: eager@eagercon.com
Cc: pkoning@equallogic.com, gdb@sourceware.org
Subject: Re: Finding ld.so dynamic loader
Date: Wed, 30 Jan 2008 21:30:00 -0000	[thread overview]
Message-ID: <200801302129.m0ULTglq028051@brahms.sibelius.xs4all.nl> (raw)
In-Reply-To: <47A0E6A2.3040101@eagercon.com> (message from Michael Eager on 	Wed, 30 Jan 2008 13:05:38 -0800)

> Date: Wed, 30 Jan 2008 13:05:38 -0800
> From: Michael Eager <eager@eagercon.com>
> 
> Paul Koning wrote:
> >>>>>> "Michael" == Michael Eager <eager@eagercon.com> writes:
> > 
> >  Michael> Mark Kettenis wrote:
> >  >> GDB tries to please them all, and still tries to cover the case of
> >  >> a native debugger too.
> > 
> >  Michael> It still seems that searching the host file system should be
> >  Michael> the last choice, not the first. 
> > 
> > It should either be the last choice, or not be done at all.  An
> > example where it should not be done at all is when host and target are
> > different architectures.  Looking up a symbol in an x86 library when
> > you're debugging a MIPS target cannot ever be correct -- but that's
> > what can happen today.  (This is also an example of something that can
> > easily be checked by the solib code without worrying about the
> > "remote" vs. "local" distinction -- if host != target then by
> > definition the host libraries are wrong.)
> 
> It's certainly incorrect to look up a symbol when the host
> and target architectures are different.  But it's also
> incorrect when the architectures are the same but the library
> versions are different.  For example, debugging a x86 Linux 2.4
> target with an x86 Linux 2.6 host.  I'd rather see a fix which
> handles both situations.

Bad example; Linux kernel versions have very little to do with this
and if both systems use the same userland things would work fine.

> Essentially, any time gdb is working with a remote target,
> searching the host file system should be suppressed.

I'm not sure everybody would agree with you here, although one could
argue that if people would want to search the host filesystem in this
case, they can always set solib-absolute-prefix and/or
solib-search-path.


  reply	other threads:[~2008-01-30 21:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-30 16:42 Michael Eager
2008-01-30 16:51 ` Daniel Jacobowitz
2008-01-30 17:00   ` Michael Eager
2008-01-30 17:47     ` Daniel Jacobowitz
2008-01-30 18:31       ` Michael Eager
2008-01-30 16:53 ` Michael Eager
2008-01-30 18:28 ` Mark Kettenis
2008-01-30 18:45   ` Michael Eager
2008-01-30 19:04     ` Paul Koning
2008-01-30 21:06       ` Michael Eager
2008-01-30 21:30         ` Mark Kettenis [this message]
2008-01-31 11:27         ` Michael Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200801302129.m0ULTglq028051@brahms.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=eager@eagercon.com \
    --cc=gdb@sourceware.org \
    --cc=pkoning@equallogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox