Re: [PATCH v4] Allow using special files with File I/O functions

[Pedro Alves <palves@redhat.com>]

On 07/09/2018 04:22 PM, Julio Guerra wrote:
> 
>>>>> Signed-off-by: Julio Guerra <julio@farjump.io>
>>>> I'm not sure whether I asked this before, but, just in case,
>>>> do you have a copyright assignment on file with the FSF?
>>>> I looked for one now and couldn't find it.
>>>>
>>> No, I don't.
>> See:
>>
>>  https://sourceware.org/gdb/wiki/ContributionChecklist#FSF_copyright_Assignment
>>
>> The request-assign.future one is most common one.  Please follow the
>> instructions at the top of the file.
> 
> Done.

Thanks.

> 
>>
>>>>> diff --git a/gdb/remote-fileio.c b/gdb/remote-fileio.c
>>>>> index 313da642ea..168590245e 100644
>>>>> --- a/gdb/remote-fileio.c
>>>>> +++ b/gdb/remote-fileio.c
>>>>> @@ -885,16 +885,9 @@ remote_fileio_func_stat (remote_target *remote, char *buf)
>>>>>        remote_fileio_return_errno (remote, -1);
>>>>>        return;
>>>>>      }
>>>>> -  /* Only operate on regular files and directories.  */
>>>>> -  if (!ret && !S_ISREG (st.st_mode) && !S_ISDIR (st.st_mode))
>>>>> -    {
>>>>> -      remote_fileio_reply (remote, -1, FILEIO_EACCES);
>>>>> -      return;
>>>>> -    }
>>>> What happens if we stat/open some kind of unsupported file type?
>>>> Do we end up with st_mode == 0 and report success anyway, or is
>>>> something else catching it and returning FILEIO_EACCES or some such?
>>>>
>>> Yes, bits SFMT of st_mode end up with everything 0 and it doesn't fail.
>>> It's like not knowing what kind of file it exactly is, but still get
>>> other values.
>> Hmm, OK.  I mildly worry whether that that might cause trouble.
>> I wonder what other filesystem network protocols do here.  Like,
>> e.g.,  nfs, sshfs, etc.
>>
> 
> The 3 options I see:
> 1 - No restrinction: this one.
> 2 - Warning: test SFMT bits and when "unsupported", set File IO SFMT
> bits to some specific FILEIO_S_UNKNOWN value.
> 3 - Restrict: strictly restrict to those SFMT types I added.
> 
> I would go for 1 or 2, to avoid another similar restriction like there
> was in open before this patch.

OK, let's try going with 1.  But please add a comment to the
effect somewhere so that it doesn't looks like it happens by accident.

>>>> I couldn't tell what's this change for?  Why did you need it?
>>> I couldn't find any other way of adding some CFLAGS and LDFLAGS to the
>>> call to the cross-compiler to link against the libc using File IOs, to
>>> add target-specific compilation flags, etc. For example, in my case:
>>>
>>>> set_board_info fileio,cflags "--specs=$sdk/Alpha.specs
>>> -mfloat-abi=hard -mfpu=vfp -march=armv6zk -mtune=arm1176jzf-s"
>>>> set_board_info fileio,ldflags "-Wl,-T$sdk/link.ld"
>> Is this something really specific to this testcase?  Don't you
>> need to do the same for all other testcases?
> 
> Yes, every other tests involving cross-compilation and the C library
> need the same.
> 
>> Did you try CC_FOR_TARGET/LD_FOR_TARGET?
> 
> I just tried and couldn't make it work. 

That's strange, because we have a few boards that rely on
those.  Grep for CC_FOR_TARGET under src/gdb/testsuite/boards/.

I actually meant to suggest CFLAGS_FOR_TARGET/LDFLAGS_FOR_TARGET,
but I don't think there's a practical difference, just like
e.g., "CC=gcc -m32" vs "CFLAGS=-m32" should end up the same in
practice.

> Common use cases are indeed
> adding extra flags but also extra files to be linked (such as the fileio
> open, read, write, ... stubs).

Thanks,
Pedro Alves