From: Raphael Zulliger <zulliger@indel.ch>
To: gdb-patches@sourceware.org
Subject: proposal: substitute-path handles foreign dir separators
Date: Fri, 17 Dec 2010 14:18:00 -0000 [thread overview]
Message-ID: <4D0B7125.2010203@indel.ch> (raw)
[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]
Hi
This is my first patch sent to this list. Please let me know if I'm
doing something wrong.
This is a not a bug fix, it's a feature: This patch extends
'substitute-path' to handle paths containing 'foreign' directory
separators. Means e.g.: A powerpc-eabi-gdb running on Linux can handle
powerpc-eabi-binaries built on Windows and vice versa.
Several points need to be considered:
1. Most importantly: Do we want such a 'feature'? Personally, I think
it makes sense to have such a feature. A prominent use case may occur
when developing for an embedded system. Having platform independent IDEs
like Eclipse together with the GNU toolchain (cygwin, mingw, *nix) makes
it possible that some members of a development team work on e.g.
Windows, while the rest works on e.g. Linux. "Working" in this case
could mean that people compile their code and probably create libraries
on their (preferred) OS. Later these libraries will be linked together
to a binary which will end up on an embedded target that needs to be
debugged. (Sure you can argue that this wouldn't happen if they'd use a
buildmachine, but...). Debugging, again, may be done by a person using
Linux or Windows. That's where this patch would become useful.
To continue the discussion lets assume that we all want this feature.
2. I created this patch because I actually debug binaries on a Linux
box which have been created on a Windows machine (GNU toolchain/Cygwin).
Empirically, I've realized that 'substitute-path' doesn't work for this
purpose. After having single-stepped GDB and modified its code slightly,
I ended up with this patch. The point is that I figured it out
empirically. It could the case that I justed missed an already existing
solution. Please let me know if my patch is crap because there exists
another way of handling my use case.
3. I didn't write any tests yet. I would write them if the patch would
get accepted. If this would be the case, it would be nice if you could
give me some hints where to start (which file, what kind of test, ...)
4. I didn't verify/test my code on any other system than Linux. I
could test it on Windows (mingw) if you would accept the patch
5. I didn't yet fill out the 'copyright assignment' form (mentioned in
the CONTRIBUTE file). I would do so if required.
Raphael
[-- Attachment #2: substitute-path.diff --]
[-- Type: text/plain, Size: 2267 bytes --]
*** /tmp/gdb-7.2/gdb/source.c 2010-12-17 14:12:11.618336763 +0100
--- gdb-7.2/gdb/source.c 2010-12-17 14:13:02.347583097 +0100
*************** substitute_path_rule_matches (const stru
*** 882,888 ****
/* Make sure that the region in the path that matches the substitution
rule is immediately followed by a directory separator (or the end of
string character). */
! if (path[from_len] != '\0' && !IS_DIR_SEPARATOR (path[from_len]))
return 0;
return 1;
--- 882,888 ----
/* Make sure that the region in the path that matches the substitution
rule is immediately followed by a directory separator (or the end of
string character). */
! if (path[from_len] != '\0' && (!IS_UNIX_DIR_SEPARATOR (path[from_len]) && !IS_DOS_DIR_SEPARATOR (path[from_len])))
return 0;
return 1;
*************** find_and_open_source (const char *filena
*** 1015,1021 ****
}
}
! if (IS_ABSOLUTE_PATH (filename))
{
/* If filename is absolute path, try the source path
substitution on it. */
--- 1015,1021 ----
}
}
! if (IS_UNIX_ABSOLUTE_PATH (filename) || IS_DOS_ABSOLUTE_PATH(filename))
{
/* If filename is absolute path, try the source path
substitution on it. */
*************** find_and_open_source (const char *filena
*** 1023,1028 ****
--- 1023,1046 ----
if (rewritten_filename != NULL)
{
+ /* Especially for embedded systems, it may be the case that a
+ binary has been built on Windows but the embedded system is now
+ being debugged on a Unix machine (and vice versa). In order to
+ make path substitution work on such 'mixed' path styles, we need
+ to convert foreign dir separators to native ones. */
+ #ifdef HAVE_DOS_BASED_FILE_SYSTEM
+ const char from = '/';
+ const char to = '\\';
+ #else
+ const char from = '\\';
+ const char to = '/';
+ #endif
+ unsigned int i=0;
+ for( i=0; i<strlen(rewritten_filename); ++i ) {
+ if( rewritten_filename[i] == from ) {
+ rewritten_filename[i] = to;
+ }
+ }
make_cleanup (xfree, rewritten_filename);
filename = rewritten_filename;
}
next reply other threads:[~2010-12-17 14:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-17 14:18 Raphael Zulliger [this message]
2010-12-17 15:26 ` Eli Zaretskii
2010-12-17 17:50 ` Pedro Alves
2010-12-17 19:23 ` Eli Zaretskii
2010-12-17 19:44 ` Pedro Alves
2010-12-17 20:11 ` Pedro Alves
2010-12-20 7:41 ` Raphael Zulliger
2010-12-22 12:00 ` Pedro Alves
2010-12-20 6:38 ` Raphael Zulliger
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=4D0B7125.2010203@indel.ch \
--to=zulliger@indel.ch \
--cc=gdb-patches@sourceware.org \
/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