Re: [PATCH] Move vgdb special case into remote_filesystem_is_local

[Pedro Alves <palves@redhat.com>]

On 05/15/2015 10:02 AM, Gary Benson wrote:
> Pedro Alves wrote:
>> On 04/27/2015 03:51 PM, Gary Benson wrote:
>>> Valgrind GDB (vgdb) presents itself as a remote target but works
>>> on the local filesystem.  gdb_bfd_open contained a special case
>>> to make vgdb work with "target:" sysroots, but the implementation
>>> meant that GDB would fall back to the local filesystem if *any*
>>> to_fileio_open method failed with ENOSYS for *any* reason.
>>
>> Can you give an example target where we'd want this to behave
>> differently?
>>
>> E.g,. what should happen with "target sim" ?
> 
> I don't understand what you're asking.  "target sim" doesn't use
> remote_filesystem_is_local, (to_filesystem_is_local for sim is
> the default, tdefault_filesystem_is_local, which returns 1 always).

When you say:

 gdb_bfd_open contained a special case
 to make vgdb work with "target:" sysroots, but the implementation
 meant that GDB would fall back to the local filesystem if *any*
 to_fileio_open method failed with ENOSYS for *any* reason.

I'd prefer to get an example target for one of those "if *any*
to_fileio_open ... *any* reason".  I'd like to understand the
real motivation for the change.  Because otherwise I get to
wonder why would we handle any other target that goes through
this path differently.

Say for example, that gdb learns to open files from
the remote target with "target mips" (remote-mips.c) as well,
for remote stubs that support it.  Seems like we'd handle ENOSYS
the same way.

I may be misunderstanding what you meant.

In any case, I guess it does make more sense to move the checks
to target_filesystem_is_local, so the target_filesystem_is_local()
checks in core code get the right result before target_fileio_open
is called (or target_fileio_readlink, etc.).  But then the patch
should be justified on those grounds.

(Note that it's not correct to say that Valgrind _always_ works on
the local filesystem.  It's just more common to run Valgrind on
the local machine, but one can well connect to a Valgrind running
on a separate machine, even one of a different arch (e.g., an ARM
GNU/Linux dev board).  The fallback is really for any remote
target that doesn't support file retrieval, and is needed because
assuming local is a better default.  I'd guess that qemu needs
it too, for example.)

Thanks,
Pedro Alves