From: Jim Blandy <jimb@redhat.com>
To: Alexander Larsson <alexl@redhat.com>
Cc: Ulrich Drepper <drepper@redhat.com>, <gdb@sources.redhat.com>
Subject: Re: Final separate debug info patch
Date: Tue, 19 Nov 2002 04:38:00 -0000 [thread overview]
Message-ID: <vt2ptt1g36s.fsf@zenia.red-bean.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0211190649570.10486-100000@devserv.devel.redhat.com>
Alexander Larsson <alexl@redhat.com> writes:
> On 19 Nov 2002, Jim Blandy wrote:
>
> >
> > Ulrich Drepper <drepper@redhat.com> writes:
> >
> > > Alexander Larsson wrote:
> > >
> > > > That makes sense to me. Uli? Is this ok with you?
> > >
> > > I don't know. I imagine that strip is used like this in the build root
> > > for the distribution. By preserving the entire path lots on unusable
> > > information is leaked and distributed. This is true for many situations.
> > >
> > > Unless somebody can provide a really good reason why the entire path is
> > > needed I rather not change anything.
> >
> > Well, my motivating case is a GDB test script that copies the
> > executable elsewhere. At the moment, I can just override the
> > compilation procedure in the target board file and run the entire GDB
> > test suite against separated executables without modifying any of the
> > test scripts. Except for this one test. Now, if strip kept an
> > absolute path when it was given one, and GDB used it, then copying the
> > executable wouldn't hurt, and everything would just work.
> >
> > If people don't want to include absolute paths, they don't have to
> > give one to strip, it seems to me. Strip preserving what it's given
> > doesn't take away anyone's choices.
>
> When i'm building in the build system i will always be using absolute
> paths to put the files in the right place. For instance for /usr/bin/app
> it will do -f $RPM_BUILD_ROOT/usr/lib/debug/usr/bin/app.debug. So we will
> leak some strange absolute paths. Of course, if gdb used the basename
> when searching the global directories that wouldn't affect the result, but
> it is sort of ugly.
I see. I'm fine with leaving the behavior as it is.
next prev parent reply other threads:[~2002-11-19 12:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-09 1:54 Alexander Larsson
2002-11-18 21:20 ` Jim Blandy
2002-11-18 21:32 ` Daniel Jacobowitz
2002-11-19 3:53 ` Jim Blandy
2002-11-18 23:47 ` Alexander Larsson
2002-11-19 3:38 ` Jim Blandy
2002-11-19 3:57 ` Alexander Larsson
2002-11-19 12:47 ` Alexander Larsson
2002-11-20 21:43 ` Jim Blandy
2002-11-20 23:35 ` Alexander Larsson
2002-11-19 5:00 ` Jim Blandy
2002-11-18 22:11 ` Jim Blandy
2002-11-18 23:51 ` Alexander Larsson
2002-11-19 0:02 ` Ulrich Drepper
2002-11-19 3:47 ` Jim Blandy
2002-11-19 3:53 ` Alexander Larsson
2002-11-19 4:38 ` Jim Blandy [this message]
2002-11-24 20:28 ` Jim Blandy
2002-11-25 5:37 ` Alexander Larsson
2002-11-25 9:44 ` Jim Blandy
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=vt2ptt1g36s.fsf@zenia.red-bean.com \
--to=jimb@redhat.com \
--cc=alexl@redhat.com \
--cc=drepper@redhat.com \
--cc=gdb@sources.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