Re: remote/1832: spaces in directory names

Re: remote/1832: spaces in directory names

[Michael Snyder]

The following reply was made to PR remote/1832; it has been noted by GNATS.

From: Michael Snyder <msnyder@redhat.com>
To: Brendan Kehoe <brendan@zen.org>
Cc: gdb-gnats@sources.redhat.com, nobody@sources.redhat.com,
        harada@esd.spr.epson.co.jp, gdb-prs@sources.redhat.com,
        gdb-patches@sources.redhat.com
Subject: Re: remote/1832: spaces in directory names
Date: Wed, 01 Mar 2006 15:55:15 -0800

 Brendan Kehoe wrote:
 
 >   - I'm curious about the mystical second argument to the LOAD command
 > in GDB; it's only mentioned in the docs related to the Sparlet, and even
 > then only in passing.
 
 It's ancient, and mostly not used any more.
 One place that does still use it is monitor.c::monitor_load (q.v.)
 
 The second argument was a base address or offset where
 you wanted the load to be relocated.  This was basically
 a hold-over from the days of a.out (in which the sections
 were assumed to start at zero).
 
 There was once a GNU extension called b.out, which was
 a.out plus a section load offset.
 
 Everything since coff has allowed an individual offset
 per section to be specified.
 
 
 

Re: remote/1832: spaces in directory names

[ams]

Synopsis: spaces in directory names

State-Changed-From-To: open->closed
State-Changed-By: ams
State-Changed-When: Wed Feb 22 12:10:33 2006
State-Changed-Why:
    Closing because generic_load() now uses build_argv() to process its input.
    
    Note that this requires that the filename is properly quoted. load_command() has been adjusted to provide properly quoted names.

http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=1832

Re: remote/1832: spaces in directory names

[Andrew STUBBS]

The following reply was made to PR remote/1832; it has been noted by GNATS.

From: Andrew STUBBS <andrew.stubbs@st.com>
To: Brendan Kehoe <brendan@zen.org>
Cc: gdb-gnats@sources.redhat.com, nobody@sources.redhat.com,
        harada@esd.spr.epson.co.jp, gdb-prs@sources.redhat.com,
        gdb-patches@sources.redhat.com
Subject: Re: remote/1832: spaces in directory names
Date: Tue, 14 Feb 2006 10:05:24 +0000

 Brendan Kehoe wrote:
 > This change makes GDB a little more willing to debug an application on a
 > remote target when the file or its path happens to have one or more
 > spaces in it.  Among other things, this makes paths like
 >    C:/Documents and Settings/Joe Smith/My Documents/hack/mytest
 > usable when you want to debug mytest on a remote target via 'load'.
 
 I already have a patch for this awaiting approval.
 
 See http://sources.redhat.com/ml/gdb-patches/2005-12/msg00127.html
 
 Mine allows/required proper quoting and supports tilde expansion.
 
 I also have two related patches waiting:
 
 directory command patch:
 http://sources.redhat.com/ml/gdb-patches/2005-12/msg00104.html
 
 add-symbol-file command patch:
 http://sources.redhat.com/ml/gdb-patches/2005-12/msg00106.html
 
 Andrew Stubbs
 

Re: remote/1832: spaces in directory names

[Brendan Kehoe]

The following reply was made to PR remote/1832; it has been noted by GNATS.

From: Brendan Kehoe <brendan@zen.org>
To: gdb-gnats@sources.redhat.com, nobody@sources.redhat.com,
	harada@esd.spr.epson.co.jp, gdb-prs@sources.redhat.com,
	gdb-patches@sources.redhat.com
Cc:  
Subject: Re: remote/1832: spaces in directory names
Date: Mon, 13 Feb 2006 17:45:45 +0000

 This change makes GDB a little more willing to debug an application on a
 remote target when the file or its path happens to have one or more
 spaces in it.  Among other things, this makes paths like
    C:/Documents and Settings/Joe Smith/My Documents/hack/mytest
 usable when you want to debug mytest on a remote target via 'load'.
 
 Two bits I'll try to bring up elsewhere but want to write down here:
   - I think it'd be better to pass the ARGS part of the on_load callback
 function as an array of pointers similar to ARGV, so you don't have to
 try to tokenize in places it might matter; and
   - I'm curious about the mystical second argument to the LOAD command
 in GDB; it's only mentioned in the docs related to the Sparlet, and even
 then only in passing.
 
 Hope this helps,
 B
 
 2006-02-13  Brendan Kehoe  <brendan@zen.org>
 
     * symfile.c (generic_load): Adjust the handling of finding any
     second/offset argument so we can properly use filenames and paths
     that use spaces, like "/home/foo/my hacks/code".  Since the
     LOAD_OFFSET is already initialized to 0 at the beginning, we
     don't need an else stmt.
 
 
 --- gdb/symfile.c.~1~    2005-08-31 22:07:33.000000000 +0100
 +++ gdb/symfile.c    2006-02-13 17:21:16.000000000 +0000
 @@ -1626,6 +1626,23 @@ generic_load (char *args, int from_tty)
    old_cleanups = make_cleanup (xfree, filename);
    strcpy (filename, args);
 -  offptr = strchr (filename, ' ');
 +  offptr = strrchr (filename, ' '); /* find the last space char */
    if (offptr != NULL)
 +  {
 +    /* Note where the space was, since that's effectively the end
 +       of the filename if we have to insert the null char.
 +       This implies we won't grok filenames that end in a space. :) */
 +    char* end_of_filename = offptr++;
 +
 +    /* As per ISO 9899 (C99) $7.20.1.4/3 and POSIX 1003.1-2001,
 +       strtoul expects a string meeting this sort of expression
 +       for an integer-constant:
 +          [\s]*[+\-]?(0[xX][0-9a-fA-F]*|[0-9]*)
 +       This will be true when its third argument, BASE, is zero.
 +       So having skipped the whitespace, we either have to have
 +       a '+' or '-', or a valid digit character.  Anything else
 +       has to be considered part of the filename.
 +     */
 +    if ((offptr[0] == '+' || offptr[0] == '-')
 +    || (isdigit (offptr[0])))
      {
        char *endptr;
 @@ -1634,8 +1651,7 @@ generic_load (char *args, int from_tty)
        if (offptr == endptr)
      error (_("Invalid download offset:%s."), offptr);
 -      *offptr = '\0';
 +      *end_of_filename = '\0';
      }
 -  else
 -    cbdata.load_offset = 0;
 +  }
  
    /* Open the file for loading. */
 

Re: remote/1832: spaces in directory names

[Harada Tomoyuki]

The following reply was made to PR remote/1832; it has been noted by GNATS.

From: Harada Tomoyuki <Harada.Tomoyuki@exc.epson.co.jp>
To: "'gdb-gnats@sources.redhat.com'" <gdb-gnats@sources.redhat.com>
Cc:  
Subject: Re: remote/1832: spaces in directory names
Date: Tue, 21 Dec 2004 17:43:29 +0900

 Although I gave arm--coff-gdb as example,
 I guess it is common problem of all target.

remote/1832: spaces in directory names

[harada]

>Number:         1832
>Category:       remote
>Synopsis:       spaces in directory names
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 21 06:58:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     harada@esd.spr.epson.co.jp
>Release:        gdb-6.3
>Organization:
>Environment:

>Description:
In directory names, if there is a space, give the following messages when execute the load command: 

"No such file or directory."

Note: this only happens when the target is a remote target. 
>How-To-Repeat:
arm--coff-gdb Program\ Files/test.exe
> set remotebaud xxxx
> target remote /dev/ttyS0
> load
<this is where the error happens>
>Fix:
symfile.c::generic_load() seems to be where the problem is.  It does not seem to be parsing the parameter list properly. 
>Release-Note:
>Audit-Trail:
>Unformatted: