Re: shared lib dos filename style - one more question

[Danny Backx <danny.backx@scarlet.be>]

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
problem.

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;
 do {
   .... all the lookups
   in_pathname = unixify (in_pathname);
   unixified++;
 } 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)
    perror_with_name (pathname);

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
considered worthwile.

	Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info