This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] testsuite: Fix some tests that write outside of the standard output/temp directories
- From: Simon Marchi <simon dot marchi at ericsson dot com>
- To: Pedro Alves <palves at redhat dot com>, <gdb-patches at sourceware dot org>
- Date: Mon, 15 Feb 2016 11:44:01 -0500
- Subject: Re: [PATCH] testsuite: Fix some tests that write outside of the standard output/temp directories
- Authentication-results: sourceware.org; auth=none
- References: <1455310904-12076-1-git-send-email-simon dot marchi at ericsson dot com> <56BE6A94 dot 3060504 at redhat dot com>
On 16-02-12 06:28 PM, Pedro Alves wrote:
> On 02/12/2016 09:01 PM, Simon Marchi wrote:
>> I used the GDB_INOTIFY feature to find those. These should be all
>> obvious changes, except for standard_temp_file and save-trace.exp.
>
> I think you should push this in 3 patches. Go ahead and push the
> obvious ones that just use standard_output_file first.
>
>>
>> I changed standard_temp_file the same way we changed
>> standard_output_file (to always return a test file-specific directory).
>> However, standard_temp_file is sometimes called when gdb_test_file_name
>> is not set, such as in gdb_init. In that case, it returns the base temp
>> directory. When running in parallel, I guess it means there is still a
>> chance of conflict between parallel test invocations. I don't think I
>> am making things worst than before though, since it was already the
>> case.
>
> As this is just a temp file, and we just need to make it unique,
> how about (always) using runtest's PID instead of gdb_test_file_name?
>
> That'd be a separate patch.
>
>>
>> In save-trace.exp, we want to test loading of a tracepoint definition
>> file with a relative path (I am not sure why in fact). We currently use
>> "savetrace-relative.tr", which ends up directly in testsuite/. If we
>> use [standard_output_file] on it, it becomes absolute. I decided to
>> just replace [pwd] with . (a dot) in that path to make it relative. It
>> wouldn't work if the [pwd] was not a prefix of the standard output
>> directory though. So I added a check to verify that precondition.
>
> Seems fine, and would be best pushed as a separate patch.
>
> Thanks,
> Pedro Alves
>
You are right, I'll push the obvious ones and send the two other fixes
separately.
Simon