This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


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

Re: [gdb/libiberty] Improve support for cross debugging shared libraries with DOS style pathnames (from Unix hosts)


On Friday 23 April 2010 09:54:17, Eli Zaretskii wrote:
> > From: Pedro Alves <pedro@codesourcery.com>
> 
> >  (gdb) help set target-file-system-kind
> >  Set assumed file system kind for target reported paths
> 
> Please don't use "path" when you really mean "file name".  It's
> confusing; "path" should be reserved for lists of directories such as
> PATH or INFOPATH.

Oh.  I really meant a "path", as in:

 "A path, the general form of a filename or of a directory name, specifies a unique
 location in a file system."

 (From <http://en.wikipedia.org/wiki/Path_%28computing%29>.)

I suppose that's why we have IS_ABSOLUTE_PATH, and not IS_ABSOLUTE_FILE_NAME,
and such.

IMO, it's the use of singular path or "search path" to mean
"list of directories" that's overloaded.
"Set assumed file system kind for target reported file names"
kind of sounds like it is only talking about the filename "/dir1/dir2/files1"
(or directory and filenames, if you think of a directory a file as well).
Maybe I could just get rid of the mention of paths/file names, and go with:

  "Set the assumed file system kind of the target."

Anyway, I'll change it to what you think is clearer.


> > --- src.orig/gdb/solib.c	2010-04-22 17:19:42.000000000 +0100
> > +++ src/gdb/solib.c	2010-04-22 17:22:34.000000000 +0100
...
> > +static const char target_file_system_kind_auto[] = "auto";
...

> Is it wise to define these in solib.c?  What about ports that don't
> link solib.c into the binary?

They don't exist.  solib.o is always linked in (it's in COMMON_OBS).

> 
> I'd suggest to move this (and the related functions) to some more
> general source file, even if for now these facilities are used only
> for shared library lookup.

Will do anyway.  Probably a new file.

> > +  /* If the search in gdb_sysroot failed, and the path name has a
> > +     drive spec (e.g, c:/foo), try stripping ':' from the drive spec,
> > +     and retrying in the sysroot:
> > +       c:/foo/bar.dll ==> /sysroot/c/foo/bar.dll.  */
> 
> Why not /sysroot/foo/bar, without the "c" part?  What systems are set
> up the way this code expects?

I'm not sure I understood what you're referring to as "systems" here.
The sysroot is a user specified path in the host file system.  If you
have a target system with more than one drive, you will want to setup
you local copies of the target system dlls like so:

 /path/to/my/sysroot/c/sys/bin/foo.dll
 /path/to/my/sysroot/c/sys/bin/bar.dll
 /path/to/my/sysroot/z/sys/bin/bar.dll

and point "set sysroot" at "/path/to/my/sysroot", so that
GDB can find the correct copies of both "c:\sys\bin\foo.dll",
and "z:\sys\bin\bar.dll".

If you don't care about multiple drives, you can
leave the "c" out of the sysroot, and gdb will still
find your host copy of the dll.  It was described as next
step in the docs:

" If that still does not find the shared library, it tries removing the
whole drive spec from the target path:

  c:/foo/bar.dll ==> /path/to/sysroot/foo/bar.dll
"

I'll be happy to clarify this in the docs, if you think it's useful.

> 
> > Index: src/gdb/i386-cygwin-tdep.c
> > ===================================================================
> > --- src.orig/gdb/i386-cygwin-tdep.c	2010-04-22 17:19:42.000000000 +0100
> > +++ src/gdb/i386-cygwin-tdep.c	2010-04-22 17:22:34.000000000 +0100
> > @@ -235,6 +235,10 @@ i386_cygwin_init_abi (struct gdbarch_inf
> >      (gdbarch, windows_core_xfer_shared_libraries);
> >  
> >    set_gdbarch_auto_wide_charset (gdbarch, i386_cygwin_auto_wide_charset);
> > +
> > +  /* Canonical paths on this target look like `c:\Program Files\Foo App\mydso.dll',
> > +     for example.  */
> > +  set_gdbarch_has_dos_based_file_system (gdbarch, 1);
> >  }
> 
> Any reasons not to provide similar settings for MinGW and DJGPP?

MinGW is also covered by i386-cygwin-tdep.c.  There's no specific
MinGW gdbarch/osabi currently.  DJGPP, it just didn't cross my mind,
probably because it doesn't support shared libraries, sorry :-)
I suppose that'll be ... in `i386_go32_init_abi'.  (Why are DJGPP
specific things in the generic i386-tdep.c, BTW?)

> 
> > +* Support for remote debugging Windows and SymbianOS shared libraries
> > +  from Unix hosts has been improved.
> 
> Is this feature really used only for remote debugging?  Doesn't it
> affect native debugging as well?
> 
> > +@smallexample
> > +  c:\foo\bar.dll ==> c:/foo/bar.dll
> > +@end smallexample
> 
> Please use @result{} instead of the ASCII art.

Eh, cool.  Will do.

> 
> > +@kindex set target-file-system-kind (unix|dos-based|auto)
> > +@kindex show target-file-system-kind
> > +@item set target-file-system-kind @var{kind}
> > +Set assumed file system kind for target reported paths.
> 
> This warrants some @cindex entry, preferably including "dos" as its
> substring.  Something like
> 
>   @cindex DOS file-name semantics if file names.

Will do.  I'll assume you meant s/if/of/.

> 
> Again, please don't use "path" instead of "file name" (here and
> elsewhere).
> 
> The NEWS entry and the patch for the manual are okay with the above
> changes.
> 
> Thanks.

Thanks.

-- 
Pedro Alves


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