From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org, Eli Zaretskii <eliz@gnu.org>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [gdb/libiberty] Improve support for cross debugging shared libraries with DOS style pathnames (from Unix hosts)
Date: Fri, 23 Apr 2010 10:46:00 -0000 [thread overview]
Message-ID: <201004231146.22671.pedro@codesourcery.com> (raw)
In-Reply-To: <83y6ge35xi.fsf@gnu.org>
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
next prev parent reply other threads:[~2010-04-23 10:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-22 17:24 Pedro Alves
2010-04-22 17:46 ` Daniel Jacobowitz
2010-04-23 8:54 ` Eli Zaretskii
2010-04-23 10:46 ` Pedro Alves [this message]
2010-04-23 11:15 ` Mark Kettenis
2010-04-23 14:30 ` Eli Zaretskii
2010-04-23 15:41 ` Mark Kettenis
2010-04-23 14:35 ` Eli Zaretskii
2010-04-24 11:18 ` Pedro Alves
2010-04-24 11:40 ` Eli Zaretskii
2010-04-24 13:13 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201004231146.22671.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=eliz@gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox