This is the mail archive of the
mailing list for the GDB project.
Re: shared lib dos filename style - one more question
On Fri, 2009-10-09 at 19:18 -0700, Joel Brobecker wrote:
> > 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
> to succeed.
Yes this is the issue.
> 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.
I like this approach, it looks better than the current one. No refresh
You write as if the caller of solib_find should have the burden, but
solib_find is not a static function so it may have more than one caller.
(Except I can only find one : solib_bfd_open.) Should this be an issue ?
Whether this is implemented in solib_find or solib_bfd_open is not a big
difference. A simplistic loop around all the stuff currently in
solib_find would probably do the trick :
unixified = 0;
.... all the lookups
in_pathname = unixify (in_pathname);
} while (unixified < 2);
When implemented in the caller (if that's a good idea), it obviously
looks simpler, something like :
found_pathname = solib_find (pathname, &found_file);
if (found_pathname == NULL)
found_pathname = solib_find (unixify (pathname), &found_file);
if (found_pathname == NULL)
But then you'd have to be sure this remains the only caller, so it would
be better to make solib_find a static function, and document this in the
comment just above solib_find.
As I said this is a better approach than the one I was using because :
- it doesn't affect libiberty
- it should automagically do the right thing
- it doesn't have the drawback of requiring funky stuff (the part I
didn't implement yet) when the user changes have_dos_based_file_system
What should unixify() do ?
1. /path/to/a -> /path/to/a
2. \path/to/a -> /path/to/a
3. \path\to\a -> /path/to/a
4. c: -> .
5. c:\path\to\a -> /path/to/a
Cases 4 and 5 will not happen in my use case (Windows CE / Windows
Mobile / .. don't have drive letters), but it looks like a good idea to
add this. Right ?
Comments please ?
> 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 :-).
This looks simple enough. Implementing this is probably the same amount
of work as doing "impact analysis" so I can do that quickly if it is
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info