Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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;
          }

             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