This is the mail archive of the
mailing list for the GDB project.
Re: shared lib dos filename style - one more question
> Gdb talks to the remote process to debug via gdbserver. This all works
> very well until you want to interact with DLLs. In some circumstances
> (e.g. with Windows Embedded CE on x86), gdb will receive DLL information
> with full paths to the DLLS.
If I understand the actual technical issue, it's that GDB fails to
compute the basename of our DLL when trying to locate it through
the solib search path. Is that correct? So you're trying to tell
GDB to use the dos FS conventions so that, when getting the basename
of your DLL, it properly computes the basename and allows the search
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.
The latter is interesting, because at the heart of the problem is
the fact that GDB no longer knows whether it's dealing with a host
filename or a remote filename. It doesn't matter in the case where
we are debugging natively. But it starts mattering when we are debugging
remotely: This is when translations start becoming required...
So far, we've been able to accomodate most/all situations encountered
in practice by little tricks such as substitute-path and
Anyway, these are only my 2 cents. Others may have different opinions,
and I suggest we reach a consensus before you go off and implement
anything. I suggest you pick one solution that you like and ask if
anyone has any problem with it :-).