Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [patch+doc 1/2] filename-display: 1->4 options {inferior,libs}{,-sepdebug}
Date: Wed, 06 Mar 2013 19:54:00 -0000	[thread overview]
Message-ID: <yjt2zjygnw2f.fsf@ruffy2.mtv.corp.google.com> (raw)
In-Reply-To: <20130227195251.GA29891@host2.jankratochvil.net>

Jan Kratochvil writes:
 > On Wed, 27 Feb 2013 20:40:08 +0100, Doug Evans wrote:
 > > 1) How common/useful would it be to distinguish shared libs of an app
 > > I've just built and installed in some private dir (or maybe
 > > /usr/local) from system shared libs?
 > > IOW treating, e.g., files in $HOME/lib/mumble different from /usr/lib/mumble.
 > > I'm not sure it's a useful distinction, just wondering.
 > 
 > I was more considering shared libraries in $HOME/src/elfutils which are part
 > of the project one is currently debugging.  Absolute pathnames are excessive
 > there, one knows the (elfutils) source tree (s)he is debugging.
 > 
 > /usr/local/lib/mumble.so I cannot reliably distinguish from $HOME/lib/mumble
 > so /usr/local/lib/mumble.so will not be handled too well by default.

We have various parameters that together specify where to find separate debug info.
Is it possible to piggyback on that?
E.g., Something minimal for now like specifying which ones are
displayed as relative with the default being none?
[And thus by default everything with separate debug info will
be displayed using absolute file names.]
Or something like that.

I wrote:
> 2) How do you see {with,without}-separate-debuginfo being used in practice?
> I'm just wondering if this choice is the core of the problem or
> whether it's system vs non-system.

Oops.  I also meant to ask about executable-vs-library.
IOW, the distinction between executables and shared libs in your patch.
There's a 2x2 matrix of {executable,shared-lib} x {embedded-debug-info,separate-debug-info}.


  reply	other threads:[~2013-03-06 19:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-15 20:25 Jan Kratochvil
2013-02-16  8:33 ` Eli Zaretskii
2013-02-18 14:33   ` Jan Kratochvil
2013-02-18 16:27     ` Eli Zaretskii
2013-02-27 19:38 ` Jan Kratochvil
2013-02-27 19:50   ` Doug Evans
2013-02-27 20:06     ` Jan Kratochvil
2013-03-06 19:54       ` Doug Evans [this message]
2013-03-07  9:52         ` Jan Kratochvil
2013-03-07 10:26           ` Pedro Alves
2013-03-07 12:01             ` Jan Kratochvil
2013-03-07 10:30         ` Pedro Alves
2013-03-07 12:04           ` Jan Kratochvil
2013-03-07 13:36             ` Pedro Alves
2013-03-07 15:07               ` Jan Kratochvil

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=yjt2zjygnw2f.fsf@ruffy2.mtv.corp.google.com \
    --to=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.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