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

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

# 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
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

> 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



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