Re: '\r' only end-of-line

Daniel Jacobowitz
2006-10-11T13:33:05Z

On Wed, Oct 11, 2006 at 12:08:07PM +0200, Denis PILAT wrote:
> >I think part of your patch is not needed: the Windows port of GDB
> >should use the LSEEK_NOT_LINEAR branch of the code in
> >find_source_lines, so the code you are patching doesn't need to
> >consider the \r\n case.
> >
> Yes but when you use a linux hosted compiler for reading windows source
> file
> (sorry for that weirdness but we sometime have common source file for
> both OS),
> then this case may happen.

I was just thinking about this the other day...

As a general position, are we willing to support things written /
compiled on other hosts? This includes both line endings and
pathnames. I hope the answer is yes, but I don't know.

At CodeSourcery, as we've said before, we ship a native Windows GDB
and GCC. But for a lot of things we have no way to test the native
Windows GDB - can't use Cygwin's expect to drive it. So I found myself
testing a Cygwin GDB using a customer's Windows-only SDK. And the
debugger got very, very unhappy because there's a filename comparison
in the dwarf reader; one of the arguments came from the compiler as
"\foo\bar.h" and the other came in two pieces "\foo" and "bar.h". GDB
assembled that as "\foo/bar.h" and FILENAME_CMP returned false.

For my local testing I wrote a filename comparison function that
allowed windows slashes. I didn't need to worry about case sensitivity
here, because Windows tools are generally case-preserving unless you
feed them input with strange casing. This was sort of unpleasant, but
useful. And in thinking about it, I think I'd rather have this return
true than false:
FILENAME_CMP ("a\\b", "a/b")

Since almost no one puts backslashes in Unix filenames (they're a
mental health hazard), and having a\\b and a/b is a truly improbable
case.

What do y'all think? Would a gdb_filename_cmp with this behavior be
OK?

--
Daniel Jacobowitz
CodeSourcery