From: Gernot Hillier <gernot.hillier@siemens.com>
To: gdb@sources.redhat.com
Subject: handling of absolute source file paths (feature wish/implementation idea)
Date: Thu, 22 Jan 2004 15:01:00 -0000 [thread overview]
Message-ID: <200401221601.17594.gernot.hillier@siemens.com> (raw)
Hi!
We use gdb for host/target debugging. As some of our targets are rather big in
respect to memory/disk space/..., we prefer to use gdb via remote login on
the target instead of using gdbserver/gdb often.
Therefore, we mount the sources from the development hosts on the target. This
means in our environment that a source file, available on the host as /a/b/
c.cpp gets mounted on /mnt/a/b/c.cpp on the target.
Unfortunately, our make environment uses absolute paths when building our
projects.
Everything worked very nice with gdb 5.3 for us by logging on to the target,
changing to /mnt and starting gdb. gdb searched absolute source code paths
not only absolute, but also relative to all given paths.
But since we switched to gdb 6.0, the target gdb isn't able to find the source
files any more because absolute paths are only searched starting from /.
We identified the reason in this change of gdb/source.c:
Revision 1.39, Mon Jan 13 20:11:47 2003 UTC by drow
* source.c (openp): If the file does not exist don't necessarily
search the path.
(see http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/
source.c.diff?r1=1.38&r2=1.39&cvsroot=src for the patch)
Now we solved the problem for us by reverting this change but we would very
much like to remove this hack and see it solved cleanly in the mainline.
We would be happy to implement a patch and send it to you for inclusion, but I
wanted to hear what you think about our ideas before doing it.
I see three ways of resolving this issue currently:
1. Reverting the change in the mainline as we did. I currently can see no real
reason why this change was made but I think there was a reason. So I assume
you won't like it, do you?
2. Implement a new setting "source-absolute-search-mode" which - when enabled
switches back to the old behaviour and tries to find absolute paths
nevertheless also relative to all given paths.
3. Implement a new setting "source-absolute-prefix" (analog to the already
existing "solib-absolute-prefix") which allows the user to set a prefix for
given absolute source code paths.
So what do you think about these ideas? Any other suggestions (besides that we
should change our make environment which is unfortunately not too easy)?
Many thanks in advance for your constructive feedback...
--
Bye,
Gernot Hillier
CT SE 2
Siemens AG, Mch P
next reply other threads:[~2004-01-22 15:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-22 15:01 Gernot Hillier [this message]
2004-01-22 15:07 ` Daniel Jacobowitz
2004-01-22 15:39 ` Gernot Hillier
2004-01-22 18:02 ` Daniel Jacobowitz
2004-01-22 16:04 ` Paul Koning
2004-01-22 17:26 ` Eli Zaretskii
2004-01-22 17:58 ` Daniel Jacobowitz
2004-03-03 17:54 ` Baurjan Ismagulov
2004-01-22 18:45 ` Andrew Cagney
2004-01-22 20:16 ` Daniel Jacobowitz
2004-01-23 13:02 ` Eli Zaretskii
2004-01-23 20:26 ` Andrew Cagney
[not found] <1074884800.30040.ezmlm@sources.redhat.com>
2004-01-23 21:31 ` Jim Ingham
2004-03-03 16:12 ` Baurjan Ismagulov
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=200401221601.17594.gernot.hillier@siemens.com \
--to=gernot.hillier@siemens.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