This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: shared lib dos filename style - one more question


On Fri, Oct 09, 2009 at 07:18:49PM -0700, Joel Brobecker wrote:
> My thoughts on that are similar to Daniel's: I don't think that we'll
> see many files on UNIX systems that start with d: or d:\, nor will we
> see a lot of backslashes either. But you never know, people like to
> shoot themselves in the foot, I've noticed.
> 
> I would agree to changing GDB so that pathnames are treated as DOS
> pathnames, modulo the case-sensitivity issue. This means that d:/
> or d:\ is treated as a drive, and that forward and backward slashes
> are treated as directory separators. I don't think we want to start
> treating filenames as case-insensitive on Unix systems.
> 
> But I think that this should still remain under control of a setting
> that allows GDB to revert to using the host filesystem convention.
> That way, if we run into unexpected issues, we can tell a user how
> to get back to the previous behavior.
> 
> Another venue that I don't think we have explored, is to fix the problem
> locally in solib:solib_find. Have we considered enhancing it in a way
> that, if solib_find found nothing, then call it again, but with a
> Unix-ified path.  If the file happens to be the in solib search path,
> it should be able to locate and return it.

There's nothing straightforward that this latter approach could do for
case-sensitivity problems, though - is there?  I'd prefer not to
completely rule out handling this case.

I wonder if the best solution wouldn't be a tri-state setting,
defaulting to 'auto' - DOS style on DOS/Windows hosts, also
recognizing forward slashes; Unix style on Unix hosts, also
recognizing drive letters and backslashes.

I haven't thought entirely about the pain involved in supporting
wrong-case files.  Maybe this is just wrong-headed... if open failed,
we'd have to do a wrong-case search, and that could get seriously out
of hand.  So maybe this is nuts...

Anyway, I'd prefer a global solution rather than one local to
solib_find.  For instance, we've had trouble with FILENAME_CMP
depending on which host the program was *compiled* on.

That's right, compiled.  It doesn't always matter what the host or
target systems are.

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]