shared lib dos filename style - one more question

shared lib dos filename style - one more question

[Danny Backx]

Hi,

I got a lot of help from several of you recently to point me in the
right direction. I am trying to get gdb to do the right thing when the
target is running on Windows Mobile (DOS filename style) and the host is
different (e.g. Linux).

This works, and I think I am close to having my patches in such a shape
that the libiberty maintainers will like them.

But the drawback for the gdb user is still that changing the variable
that steers this functionality often comes too late. The names are
processed when connecting to the target, changing the variable doesn't
affect gdb's operation any more. (See the session below, it also shows a
rather ugly workaround.)

My question : can anyone point me to where I should rerun some gdb
function when the gdb user changes the value of this variable ? I
already figured out that the shlib info gets passed when "solib_add" is
called, but is that what I need to rerun ?

Thanks,

	Danny

pavilion: {580} ./gdb ~/tmp/arm/test/remedy.nl/shlib/4.stdc
++/usedemo.exe
GNU gdb (GDB) 6.8.50.20090905-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=i386-mingw32ce".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc
++/usedemo.exe...done.
(gdb) set dos_based_file_system off
(gdb) set
solib-search-path /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc
++:/opt/x86mingw32ce/bin:/opt/x86mingw32ce/i386-mingw32ce/lib
(gdb) target remote ebox:9999
Remote debugging using ebox:9999
Error while mapping shared library sections:
\network\x86\libgcc_s_sjlj-1.dll: No such file or directory.
Error while mapping shared library sections:
\network\x86\libstdc++-6.dll: No such file or directory.
Error while mapping shared library sections:
\network\x86\libx.dll: No such file or directory.
Error while mapping shared library sections:
coredll.dll: No such file or directory.
Symbol file not found for \network\x86\libgcc_s_sjlj-1.dll
Symbol file not found for \network\x86\libstdc++-6.dll
Symbol file not found for \network\x86\libx.dll
Symbol file not found for coredll.dll
WinMainCRTStartup (hInst=0x5f0000e, hPrevInst=0x0, lpCmdLine=0x3601fc70
L"", nCmdShow=5)

at /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/mingw/crt3.c:35
35      {
(gdb) info share
From        To          Syms Read   Shared Object Library
                        No          \network\x86\libgcc_s_sjlj-1.dll
                        No          \network\x86\libstdc++-6.dll
                        No          \network\x86\libx.dll
                        No          coredll.dll
(gdb) set dos_based_file_system on

Note 1 : here is where I would like to interfere so the paths get
processed again, with the new value of have_dos_based_file_system .


(gdb) info share
From        To          Syms Read   Shared Object Library
                        No          \network\x86\libgcc_s_sjlj-1.dll
                        No          \network\x86\libstdc++-6.dll
                        No          \network\x86\libx.dll
                        No          coredll.dll

Note 2 : disconnecting and connecting again is a workaround for not
having the functionality I still lack now.


(gdb) disconnect
Ending remote debugging.
(gdb) set dos_based_file_system on
(gdb) target remote ebox:9999
Remote debugging using ebox:9999
Error while mapping shared library sections:
coredll.dll: No such file or directory.
Reading symbols from /opt/x86mingw32ce/bin/libgcc_s_sjlj-1.dll...done.
Loaded symbols for /opt/x86mingw32ce/bin/libgcc_s_sjlj-1.dll
Reading symbols from /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc
++-6.dll...done.
Loaded symbols for /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc++-6.dll
Reading symbols from /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc
++/libx.dll...done.
Loaded symbols for /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc
++/libx.dll
Symbol file not found for coredll.dll
WinMainCRTStartup (hInst=0x5f0000e, hPrevInst=0x0, lpCmdLine=0x3601fc70
L"", nCmdShow=5)

at /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/mingw/crt3.c:35
35      {
(gdb) info share
From        To          Syms Read   Shared Object Library
0x42371000  0x4237c1fc
Yes         /opt/x86mingw32ce/bin/libgcc_s_sjlj-1.dll
0x41f01000  0x41fd2988
Yes         /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc++-6.dll
0x41ee1000  0x41ee7068
Yes         /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc++/libx.dll
                        No          coredll.dll
(gdb) 
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: shared lib dos filename style - one more question

[Danny Backx]

[-- Attachment #1: Type: text/plain, Size: 5261 bytes --]

No reply to the message below. I'm including my current work now. Please
comment.

	Danny

On Sat, 2009-09-26 at 15:51 +0200, Danny Backx wrote:
> Hi,
> 
> I got a lot of help from several of you recently to point me in the
> right direction. I am trying to get gdb to do the right thing when the
> target is running on Windows Mobile (DOS filename style) and the host is
> different (e.g. Linux).
> 
> This works, and I think I am close to having my patches in such a shape
> that the libiberty maintainers will like them.
> 
> But the drawback for the gdb user is still that changing the variable
> that steers this functionality often comes too late. The names are
> processed when connecting to the target, changing the variable doesn't
> affect gdb's operation any more. (See the session below, it also shows a
> rather ugly workaround.)
> 
> My question : can anyone point me to where I should rerun some gdb
> function when the gdb user changes the value of this variable ? I
> already figured out that the shlib info gets passed when "solib_add" is
> called, but is that what I need to rerun ?
> 
> Thanks,
> 
> 	Danny
> 
> pavilion: {580} ./gdb ~/tmp/arm/test/remedy.nl/shlib/4.stdc
> ++/usedemo.exe
> GNU gdb (GDB) 6.8.50.20090905-cvs
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu
> --target=i386-mingw32ce".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc
> ++/usedemo.exe...done.
> (gdb) set dos_based_file_system off
> (gdb) set
> solib-search-path /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc
> ++:/opt/x86mingw32ce/bin:/opt/x86mingw32ce/i386-mingw32ce/lib
> (gdb) target remote ebox:9999
> Remote debugging using ebox:9999
> Error while mapping shared library sections:
> \network\x86\libgcc_s_sjlj-1.dll: No such file or directory.
> Error while mapping shared library sections:
> \network\x86\libstdc++-6.dll: No such file or directory.
> Error while mapping shared library sections:
> \network\x86\libx.dll: No such file or directory.
> Error while mapping shared library sections:
> coredll.dll: No such file or directory.
> Symbol file not found for \network\x86\libgcc_s_sjlj-1.dll
> Symbol file not found for \network\x86\libstdc++-6.dll
> Symbol file not found for \network\x86\libx.dll
> Symbol file not found for coredll.dll
> WinMainCRTStartup (hInst=0x5f0000e, hPrevInst=0x0, lpCmdLine=0x3601fc70
> L"", nCmdShow=5)
> 
> at /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/mingw/crt3.c:35
> 35      {
> (gdb) info share
> >From        To          Syms Read   Shared Object Library
>                         No          \network\x86\libgcc_s_sjlj-1.dll
>                         No          \network\x86\libstdc++-6.dll
>                         No          \network\x86\libx.dll
>                         No          coredll.dll
> (gdb) set dos_based_file_system on
> 
> Note 1 : here is where I would like to interfere so the paths get
> processed again, with the new value of have_dos_based_file_system .
> 
> 
> (gdb) info share
> >From        To          Syms Read   Shared Object Library
>                         No          \network\x86\libgcc_s_sjlj-1.dll
>                         No          \network\x86\libstdc++-6.dll
>                         No          \network\x86\libx.dll
>                         No          coredll.dll
> 
> Note 2 : disconnecting and connecting again is a workaround for not
> having the functionality I still lack now.
> 
> 
> (gdb) disconnect
> Ending remote debugging.
> (gdb) set dos_based_file_system on
> (gdb) target remote ebox:9999
> Remote debugging using ebox:9999
> Error while mapping shared library sections:
> coredll.dll: No such file or directory.
> Reading symbols from /opt/x86mingw32ce/bin/libgcc_s_sjlj-1.dll...done.
> Loaded symbols for /opt/x86mingw32ce/bin/libgcc_s_sjlj-1.dll
> Reading symbols from /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc
> ++-6.dll...done.
> Loaded symbols for /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc++-6.dll
> Reading symbols from /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc
> ++/libx.dll...done.
> Loaded symbols for /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc
> ++/libx.dll
> Symbol file not found for coredll.dll
> WinMainCRTStartup (hInst=0x5f0000e, hPrevInst=0x0, lpCmdLine=0x3601fc70
> L"", nCmdShow=5)
> 
> at /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/mingw/crt3.c:35
> 35      {
> (gdb) info share
> >From        To          Syms Read   Shared Object Library
> 0x42371000  0x4237c1fc
> Yes         /opt/x86mingw32ce/bin/libgcc_s_sjlj-1.dll
> 0x41f01000  0x41fd2988
> Yes         /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc++-6.dll
> 0x41ee1000  0x41ee7068
> Yes         /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc++/libx.dll
>                         No          coredll.dll
> (gdb) 
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

[-- Attachment #2: gdb-diff.gz --]
[-- Type: application/x-gzip, Size: 6606 bytes --]

Re: shared lib dos filename style - one more question

[Daniel Jacobowitz]

On Wed, Oct 07, 2009 at 10:07:55PM +0200, Danny Backx wrote:
> No reply to the message below. I'm including my current work now. Please
> comment.

I've been staying out of this conversation because I don't have time
to discuss it properly, but I am still skeptical that this should ever
be a user setting - I've yet to see a plausible problem if we always
handled both styles of filesystem.

If it does need to be a user setting, IMO it's acceptable to make
users set it in their .gdbinit or on the GDB command line.

-- 
Daniel Jacobowitz
CodeSourcery

Re: shared lib dos filename style - one more question

[Danny Backx]

On Wed, 2009-10-07 at 16:11 -0400, Daniel Jacobowitz wrote:
> On Wed, Oct 07, 2009 at 10:07:55PM +0200, Danny Backx wrote:
> > No reply to the message below. I'm including my current work now. Please
> > comment.
> 
> I've been staying out of this conversation because I don't have time
> to discuss it properly, but I am still skeptical that this should ever
> be a user setting - I've yet to see a plausible problem if we always
> handled both styles of filesystem.
> 
> If it does need to be a user setting, IMO it's acceptable to make
> users set it in their .gdbinit or on the GDB command line.

I'm sure that any effects of discouragement at my end are not the
intention of this message :-)

I'm perfectly willing to continue work on this (makes no sense to drop
it now), but I'd like to know where to go from here.

I'll ask some questions, maybe this'll give clarity :
1. If this work (or the way it's currently implemented) is questionable,
   then why have an effect on libiberty ?
   So : do we want this to go as far as extending libiberty slightly ?
2. This may all be much too complicated. Stuff the solution, make sure
   that forward slashes as well as backslashes as well as C:/ stuff
   are always supported.
   A very good or a very bad idea ?
   It would conflict with the "let's take this one step at a time" that
   someone told me.
3. Great idea. We'll get more of this soon. But let's not go further
   right now. Implement it as is, don't go the extra mile to re-
   evaluate everything if the user changes the variable in the middle
   of a session.
   What's good or bad about this ?
4. gdbserver is a bad idea. gdb shouldn't bother with debugging
   architectures that look different from the development host.
   I'm not sure what the question is here.

These may be bad questions but it feels like the right time to stir up
the discussion.

	Danny

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

Re: shared lib dos filename style - one more question

[Joel Brobecker]

> I'm sure that any effects of discouragement at my end are not the
> intention of this message :-)

This just shows how important it is to agree on user-level design
before digging into the implementation - when you can of course.
Not saying that you didn't!

I actually missed that discussion. Would you mind maybe explain again
what it is that you're trying to achieve and what has been said on
the subject? I promise I will read through it and try to give you my
answers to your questions.

-- 
Joel

Re: shared lib dos filename style - one more question

[Danny Backx]

On Fri, 2009-10-09 at 10:36 -0700, Joel Brobecker wrote:
> > I'm sure that any effects of discouragement at my end are not the
> > intention of this message :-)
> 
> This just shows how important it is to agree on user-level design
> before digging into the implementation - when you can of course.
> Not saying that you didn't!
> 
> I actually missed that discussion. Would you mind maybe explain again
> what it is that you're trying to achieve and what has been said on
> the subject? I promise I will read through it and try to give you my
> answers to your questions.

Sure. Note that I'm not discouraged yet, but I would like people to step
into the discussion *now*, not after I'm pointed in another direction.

What am I trying to accomplish ?

Consider http://sf.net/projects/cegcc - cross-develop from your
favourite host to target the Windows CE family (Windows Mobile,
PocketPC, Windows Embedded CE, ..).

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.

Those paths are in windows style, while the gdb (if on e.g. Linux) only
knows about Unix style paths. From that point on, everything related to
shared libraries fails : e.g. querying at which addresses a DLL is
loaded.

My goal is to fix that.

An example session is in
http://sourceware.org/ml/gdb-patches/2009-09/msg00223.html

You can follow that thread to the rest of the discussion.

At one point I was talking to the BFD maintainers, that was due to my
own misunderstanding. So there's stuff on the BFD list, but probably not
important.

Another interaction is on the gcc mailing list, due to impact on
libiberty. I have the feeling that my current code can be accepted there
if the solution it is created for is considered (by the gdb crowd) to be
the right one.

Please don't misunderstand me : I'm not interested in a particular
solution. The simple one - that was suggested by Daniel this week - is
perfectly acceptable to me; I'll end up considering the coding I did for
it as work necessary for impact analysis. No harm done.

Thanks for looking into this.

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

Re: shared lib dos filename style - one more question

[Joel Brobecker]

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

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
solib-search-patch.

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 :-).

-- 
Joel

Re: shared lib dos filename style - one more question

[Danny Backx]

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

Re: shared lib dos filename style - one more question

[Eli Zaretskii]

> From: Danny Backx <danny.backx@scarlet.be>
> Cc: Daniel Jacobowitz <drow@false.org>,         gdb-patches <gdb-patches@sourceware.org>
> Date: Mon, 12 Oct 2009 22:07:06 +0200
> 
> 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

If unixify is supposed to support Windows file semantics, then the
last 2 cases are incorrect, IMO.  4 should return "c:." and 5
"c:/path/to/a".

Re: shared lib dos filename style - one more question

[Joel Brobecker]

> > 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
> 
> If unixify is supposed to support Windows file semantics, then the
> last 2 cases are incorrect, IMO.  4 should return "c:." and 5
> "c:/path/to/a".

Actually, I think in this case "unixify" would mean trying to make
sense out of Windows path on a Unix machine: The target sent us
c:\path\to\dll, and we're trying to find that dll on the host.
So best guess on the host is probably /path/to/dll.  After that,
we should be able to use the root prefix setting, if necessary,
in order to find the file on the host.

-- 
Joel

Re: shared lib dos filename style - one more question

[Pedro Alves]

On Tuesday 13 October 2009 06:24:37, Joel Brobecker wrote:
> 
> > If unixify is supposed to support Windows file semantics, then the
> > last 2 cases are incorrect, IMO.  4 should return "c:." and 5
> > "c:/path/to/a".
> 
> Actually, I think in this case "unixify" would mean trying to make
> sense out of Windows path on a Unix machine: The target sent us
> c:\path\to\dll, and we're trying to find that dll on the host.
> So best guess on the host is probably /path/to/dll.  After that,
> we should be able to use the root prefix setting, if necessary,
> in order to find the file on the host.
> 

That leaves out drives other than "c:", unlike Eli's version.
Do we always want to discard that possibility?
If the "c:/" isn't there, then at least a "c/" could be, so that
you can still map a "d:" using directories or symlinks on
the host, something like this:

 /sysroot/c/path/to/a
 /sysroot/d/path/to/b

Leaving the ':' in:

 /sysroot/c:/path/to/a
 /sysroot/d:/path/to/b

The former, without ':' allows using the same sysroot
on a Windows host, since I don't think you can create
directories with ':' there.

(
 Wine maps a "sysroot" similarly:

  ls -als .wine/dosdevices/
  c: -> ../harddiskvolume1
  d: -> ../harddiskvolume2
  z: -> /

 Look, a file named 'c:' on a unix box! Okay, this
 case doesn't really count.  :-)
)


Worth considering, IMHO, perhaps as an optional mode,
similar (or exactly like) to Daniel's tri-state
setting suggestion.

-- 
Pedro Alves

Re: shared lib dos filename style - one more question

[Joel Brobecker]

>  /sysroot/c/path/to/a
>  /sysroot/d/path/to/b
> 
> Leaving the ':' in:
> 
>  /sysroot/c:/path/to/a
>  /sysroot/d:/path/to/b

Good point. Either form works for me.

-- 
Joel

Re: shared lib dos filename style - one more question

[Eli Zaretskii]

> Date: Tue, 13 Oct 2009 08:29:49 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org, Eli Zaretskii <eliz@gnu.org>,
> 	danny.backx@scarlet.be, drow@false.org
> 
> >  /sysroot/c/path/to/a
> >  /sysroot/d/path/to/b
> > 
> > Leaving the ':' in:
> > 
> >  /sysroot/c:/path/to/a
> >  /sysroot/d:/path/to/b
> 
> Good point. Either form works for me.

I vote for the second, because it covers the case that the colon is
part of a real Unix file name.

Re: shared lib dos filename style - one more question

[Eli Zaretskii]

> Date: Mon, 12 Oct 2009 22:24:37 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: danny.backx@scarlet.be, drow@false.org, gdb-patches@sourceware.org
> 
> > > 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
> > 
> > If unixify is supposed to support Windows file semantics, then the
> > last 2 cases are incorrect, IMO.  4 should return "c:." and 5
> > "c:/path/to/a".
> 
> Actually, I think in this case "unixify" would mean trying to make
> sense out of Windows path on a Unix machine: The target sent us
> c:\path\to\dll, and we're trying to find that dll on the host.

What is the use-case in which this can happen?

Re: shared lib dos filename style - one more question

[Daniel Jacobowitz]

On Tue, Oct 13, 2009 at 08:13:47PM +0200, Eli Zaretskii wrote:
> What is the use-case in which this can happen?

For shared libraries, the case where GDB runs on a host Unix system
and gdbserver runs on a target Windows or WinCE system.

For source file paths, the case where GDB runs on a Unix system
but the project was compiled on a Windows system.

-- 
Daniel Jacobowitz
CodeSourcery

Re: shared lib dos filename style - one more question

[Daniel Jacobowitz]

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

Re: shared lib dos filename style - one more question

[Joel Brobecker]

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

Hmmm, I was indeed carefully side-stepping this issue, busted :).
I was hoping that this wasn't going to matter in practice...

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

I guess this could indeed get seriously out of hand, but I'm not
so sure about that. I'm thinking we could rapidly fail within
the first few elements of the path. But regardless, having a tri-state
setting should help prevent that - only the users requiring
case-insensitive matching on Unix hosts would be paying the potential
cost.

> Anyway, I'd prefer a global solution rather than one local to
> solib_find.

Me too.

-- 
Joel

Re: shared lib dos filename style - one more question

[Daniel Jacobowitz]

On Mon, Oct 12, 2009 at 10:21:01PM -0700, Joel Brobecker wrote:
> > 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.
> 
> Hmmm, I was indeed carefully side-stepping this issue, busted :).
> I was hoping that this wasn't going to matter in practice...

I've worked with a build system (for a mobile phone OS) that uppercase
all filenames halfway through the build process.  So which case you
get in debug info is pretty hard to predict.

-- 
Daniel Jacobowitz
CodeSourcery

Re: shared lib dos filename style - one more question

[Danny Backx]

On Tue, 2009-10-13 at 20:25 +0200, Eli Zaretskii wrote:
> > >  /sysroot/c:/path/to/a
> > >  /sysroot/d:/path/to/b
> > 
> > Good point. Either form works for me.
> 
> I vote for the second, because it covers the case that the colon is
> part of a real Unix file name.

Ok so I guess the table becomes :

> 1.  /path/to/a -> /path/to/a
> 2.  \path/to/a -> /path/to/a
> 3.  \path\to\a -> /path/to/a
> 4.  c: -> c:
> 5.  c:\path\to\a -> c:/path/to/a

so the only thing that happens is backslash to forward slash
translation.

Right ?

On Mon, 2009-10-12 at 16:44 -0400, Daniel Jacobowitz wrote:
> 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.

Do you mean that the call to unixify() should happen in openp() instead
of in solib_find() ? There's also a call to open() so I guess this
should be changed as well.

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

Re: shared lib dos filename style - one more question

[Joel Brobecker]

> Ok so I guess the table becomes :
> 
> > 1.  /path/to/a -> /path/to/a
> > 2.  \path/to/a -> /path/to/a
> > 3.  \path\to\a -> /path/to/a
> > 4.  c: -> c:
> > 5.  c:\path\to\a -> c:/path/to/a
> 
> so the only thing that happens is backslash to forward slash
> translation.

That is also my understanding from the previous discussions,
except also for the case insensitivity.

> Do you mean that the call to unixify() should happen in openp() instead
> of in solib_find() ? There's also a call to open() so I guess this
> should be changed as well.

It's a little foggy in my memory, right now, and I don't have much
time to dig further.  But you have to be a little careful - I don't
think a call to open can be replaced by a call to openp. But what
Daniel probably meant was that we shouldn't limit this solution to
just solib_find.  So yes, probably something in in openp. Or perhaps
a new routine that does DOS-style file matching on Unix hosts that
openp and solib_find could call.

-- 
Joel