Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: asmwarrior <asmwarrior@gmail.com>
To: Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] Fix problems related to Mingw/DJGPP file names containing colons
Date: Sat, 13 Aug 2011 01:20:00 -0000	[thread overview]
Message-ID: <4E45D1AE.204@gmail.com> (raw)
In-Reply-To: <7973.24406817115$1313164244@news.gmane.org>

On 2011-8-12 23:50, Pierre Muller wrote:
>    Using current CVS source,
> I am unable to handle files having Dos style
> directory specifications inside the stabs debugging information
> (but I don't think that this is stabs specific).
> Release 7.3 has the same problem...
>
>    The program test.exe below has been compiled with Free Pascal
> for win32 target (more or less mingw).
>    When I try to insert a break point at a line of current file,
> the addr_string computed is "e:/pas/trunk/fpcsrc/ide/test.pas:166".
>    But locate_first_half function stops at the first colon
> and GDB complains because file "e" is not found.
>
>    I first tried to add double-quotes around the file name,
> but this was not enough... I suspect that the other changes
> below that I had to add are just errors in the current implementation...
>    See below for submitted patch.
>
>    Nevertheless, this implementation will probably fail miserably for
> file names containing double-quotes, not sure if this is allowed
> on some OS's or FileSystems...
>
>    Comments most welcome
> Pierre Muller
> GDB pascal language maintainer
>
>
>>>>> GDB session illustrating the problem
>
> E:\pas\trunk\fpcsrc\ide>gdbcvsmult test
> GNU gdb (GDB) 7.3.50.20110805-cvs
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-pc-mingw32".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from E:\pas\trunk\fpcsrc\ide/test.exe...done.
> (gdb) li main
> 157     end;
> 158
> 159     var i,j : longint;
> 160         Length : longint;
> 161
> 162     BEGIN
> 163     {$ifdef m68k}
> 164       asm
> 165         beq @L13
> 166         bhi @L13
> (gdb) b 166
> Breakpoint 1 at 0x40170d: file e:/pas/trunk/fpcsrc/ide/test.pas, line 166.
> (gdb) r
> Starting program: E:\pas\trunk\fpcsrc\ide/test.exe
> [New Thread 1116.0xe38]
> Error in re-setting breakpoint 1: No source file named e.
> Obj1.Z=1
> Hello world!
> ParamCount = 0
> Paramstr(0) = E:\pas\trunk\fpcsrc\ide\test.exe
> FALSE
> dummy for browser
> dummy for browser
> 0
> [Inferior 1 (process 1116) exited with code 04]
> (gdb)
>
>
>
>
>
>
> 2011-08-12  Pierre Muller<muller@ics.u-strasbg.fr>
>
> 	* linespec.c (build_canonical_line_spec): Handle Dos style filenames
> 	by adding double-quotes around the file name.
> 	(locate_first_half): Exit at the end of double-quoted part.
> 	Never stop inside double-quoted part.
> 	(symtab_from_filename): Move past the ending double-quote if
> 	IS_QUOTE_ENCLOSED is set.
>
>
> Index: src/gdb/linespec.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/linespec.c,v
> retrieving revision 1.128
> diff -u -p -r1.128 linespec.c
> --- src/gdb/linespec.c	5 Jul 2011 20:30:19 -0000	1.128
> +++ src/gdb/linespec.c	12 Aug 2011 15:30:43 -0000
> @@ -455,7 +455,11 @@ build_canonical_line_spec (struct symtab
>     else
>       {
>         canonical_name = xmalloc (strlen (filename) + 30);
> -      sprintf (canonical_name, "%s:%d", filename, sal->line);
> +      /* Quote filenames containing ':' characters to avoid problems.  */
> +      if (strchr (filename, ':') != NULL&&  filename[0] != '"')
> +	sprintf (canonical_name, "\"%s\":%d", filename, sal->line);
> +      else
> +	sprintf (canonical_name, "%s:%d", filename, sal->line);
>       }
>     canonical_arr[0] = canonical_name;
>   }
> @@ -1214,12 +1218,16 @@ locate_first_half (char **argptr, int *i
>   	{
>   	  break;
>   	}
> +      /* Consider a double quote to be the end of the first half.  */
> +      if (*is_quote_enclosed&&  p[0] == '"')
> +	return p;
> +
>         /* Check for the end of the first half of the linespec.  End of
>            line, a tab, a colon or a space.  But if enclosed in double
> -	 quotes we do not break on enclosed spaces.  */
> +	 quotes we do not break on enclosed spaces, nor on colons.  */
>         if (!*p
>   	  || p[0] == '\t'
> -	  || (p[0] == ':')
> +	  || ((p[0] == ':')&&  !*is_quote_enclosed)
>   	  || ((p[0] == ' ')&&  !*is_quote_enclosed))
>   	break;
>         if (p[0] == '.'&&  strchr (p, ':') == NULL)
> @@ -1796,12 +1804,10 @@ symtab_from_filename (char **argptr, cha
>     char *p1;
>     char *copy;
>     struct symtab *file_symtab;
> -
> +
>     p1 = p;
>     while (p != *argptr&&  p[-1] == ' ')
>       --p;
> -  if ((*p == '"')&&  is_quote_enclosed)
> -    --p;
>     copy = (char *) alloca (p - *argptr + 1);
>     memcpy (copy, *argptr, p - *argptr);
>     /* It may have the ending quote right after the file name.  */
> @@ -1822,8 +1828,11 @@ symtab_from_filename (char **argptr, cha
>         throw_error (NOT_FOUND_ERROR, _("No source file named %s."), copy);
>       }
>
> +  if (p1[0] == '"'&&  is_quote_enclosed)
> +    p1++;
>     /* Discard the file name from the arg.  */
>     p = p1 + 1;
> +
>     while (*p == ' ' || *p == '\t')
>       p++;
>     *argptr = p;
>
>
It is exact the problem I reported here:
http://sourceware.org/bugzilla/show_bug.cgi?id=12843

As Keith said, I can solve this problem only by revert this change:
------------------------------
if (!*p
|| p[0] == '\t'
- || ((p[0] == ':')
- && ((p[1] == ':') || (strchr (p + 1, ':') == NULL)))
+ || (p[0] == ':')
|| ((p[0] == ' ') && !*is_quote_enclosed))
------------------------------

Then, everything works fine.

@Pierre Muller:
I think adding quotes internally is not quite good. That's from my 
personal point.

there is another issue when locating the absolute the source path if the 
app is build with relative paths. I have a patch to solve them in that 
following discussion.

http://sourceware.org/ml/gdb/2011-06/msg00102.html
a simplified patch used on mingw official 7.3 release can be found here:
http://article.gmane.org/gmane.comp.gnu.mingw.user/37199


asmwarrior
ollydbg from codeblocks' forum


       reply	other threads:[~2011-08-13  1:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <7973.24406817115$1313164244@news.gmane.org>
2011-08-13  1:20 ` asmwarrior [this message]
     [not found] <004901cc5907$85006320$8f012960$%muller@ics-cnrs.unistra.fr>
2011-08-12 17:17 ` Eli Zaretskii
2011-08-12 17:25   ` Tom Tromey
2011-08-12 17:47     ` Eli Zaretskii
2011-08-13 10:11       ` Pierre Muller
     [not found]       ` <003c01cc59a1$49cc1520$dd643f60$%muller@ics-cnrs.unistra.fr>
2011-08-13 10:50         ` Eli Zaretskii
2011-08-13 20:42           ` Pierre Muller
2011-08-13 20:51             ` DJ Delorie
2011-08-13 21:26             ` Mark Kettenis
2011-08-15 19:29               ` Tom Tromey
     [not found]           ` <28604.9419818029$1313268187@news.gmane.org>
2011-08-15 19:21             ` Tom Tromey
2011-08-12 15:50 Pierre Muller
2011-08-12 17:00 ` Keith Seitz

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=4E45D1AE.204@gmail.com \
    --to=asmwarrior@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pierre.muller@ics-cnrs.unistra.fr \
    /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