From: Aleksandar Ristovski <aristovski@qnx.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] new substitute path when loading feature
Date: Tue, 13 May 2008 20:24:00 -0000 [thread overview]
Message-ID: <4829E42D.4050105@qnx.com> (raw)
In-Reply-To: <20080513181131.GA9899@caradoc.them.org>
Daniel Jacobowitz wrote:
> On Tue, May 13, 2008 at 02:06:57PM -0400, Aleksandar Ristovski wrote:
>> To properly translate the paths it is useful to be able to tell gdb
>> to translate such paths into new environment. Existing
>> "substitute-path" functionality seems like the most logical choice,
>> and the diff exploits this to add new feature - rewriting source
>> paths at readin time.
>
> Why is this feature useful? There shouldn't be anything that depends
> on the paths being changed at readin time.
>
This is what prompted my change:
(gdb) set substitute-path c:/Temp /tmp
(gdb) symbol-file /tmp/dirs/debug/main2
Reading symbols from /tmp/dirs/debug/main2...done.
(gdb) b main
Breakpoint 1 at 0x8048418: file c:/Temp/dirs/main.c, line 3.
(gdb) l
1 c:/Temp/dirs/main.c: No such file or directory.
in c:/Temp/dirs/main.c
(gdb)
Now without my change, this will sometimes work, sometimes it won't. For example, if the program was compiled on windows like this:
C:\Temp\dirs\debug>gcc -g -O0 -c ../main.c -o main.o
things would work. However if built like this:
C:\Temp\dirs\debug>gcc -g -O0 -c c:\Temp\dirs\main.c -o main.o
things would not work (as shown above).
My other motivation was that throughout the code we use IS_ABSOLUTE_PATH which simply doesn't work if gdb was not configured for that filesystem flavour (i.e. when configured for POSIX path it does not understand Win32 path naming). With rewriting paths at source, things work as expected.
Further, in most cases when file lookup is done and binary contains alien path style (well, only when gdb is configured for POSIX but examinig win32 built binary) the path matches happen mostly by chance, i.e. by matching basename and not full path. This may (and probably will) cause problems every now and then when a binary contains two source files (whether CU or included file) with the same base name.
In any case, it seems right to be able to rewrite paths at readin and let gdb "see" the binaries as if they were built locally.
Thanks,
Aleksandar
next prev parent reply other threads:[~2008-05-13 18:56 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-13 18:56 Aleksandar Ristovski
2008-05-13 19:00 ` Daniel Jacobowitz
2008-05-13 20:24 ` Aleksandar Ristovski [this message]
2008-05-13 21:11 ` Daniel Jacobowitz
2008-05-13 21:18 ` Aleksandar Ristovski
2008-05-13 21:40 ` Daniel Jacobowitz
2008-05-15 17:37 ` Daniel Jacobowitz
2008-05-15 19:29 ` Joel Brobecker
2008-05-15 19:30 ` Eli Zaretskii
2008-05-15 19:44 ` Daniel Jacobowitz
2008-05-15 22:40 ` Eli Zaretskii
2008-05-16 0:28 ` Daniel Jacobowitz
2008-05-16 8:15 ` Aleksandar Ristovski
2008-05-16 8:19 ` Aleksandar Ristovski
2008-05-16 8:21 ` Daniel Jacobowitz
2008-05-16 15:26 ` Mark Kettenis
2008-05-16 15:27 ` Eli Zaretskii
2008-05-16 15:27 ` Aleksandar Ristovski
2008-05-16 15:27 ` Eli Zaretskii
2008-05-16 19:21 ` Aleksandar Ristovski
2008-05-16 19:35 ` Eli Zaretskii
2008-05-16 19:22 ` Aleksandar Ristovski
2008-05-16 15:27 ` Aleksandar Ristovski
2008-05-16 15:26 ` Eli Zaretskii
2008-05-15 20:05 ` Joel Brobecker
2008-05-15 19:35 ` Aleksandar Ristovski
2008-05-17 19:49 ` Vladimir Prus
2008-05-19 4:12 ` Vladimir Prus
2008-05-13 21:12 ` Eli Zaretskii
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=4829E42D.4050105@qnx.com \
--to=aristovski@qnx.com \
--cc=drow@false.org \
--cc=gdb-patches@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