Re: [patch+doc 1/2] filename-display: 1->4 options {inferior,libs}{,-sepdebug}

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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.

But /usr/local/lib/mumble.so will be handled the same way as it is so it is
not a regression.


> 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.

The goal is to apply the [patch 2/2] so what "with-separate-debuginfo" is used
as identification of system libraries and therefore print absolute source
pathnames for them with GDB by default.


> [I understand the reasoning behind the previous version of the patch,
> it's a problem that I as a distro user would want solved.
> with-separate-debuginfo is a good proxy for system files, it's just
> not good enough  for me.  Sorry!]

I still do not understand what solution would be good for you, what is your
usecase?

This patchset tries to fix the obviously wrong case - displaying relative
source pathnames for system libraries of common distros.

This patchset does not automatically fix some other /usr/local or $HOME cases
as I have not found a safe auto-detection for them.  You can use
	echo >>~/.gdbinit set filename-display absolute
or
	echo >>$HOME/src/project/bin-gdb.gdb set filename-display absolute
for such cases.


Thanks,
Jan