On Thu, Jun 28, 2012 at 6:50 AM, Matthew Gretton-Dann
<matthew.gretton-d...@arm.com> wrote:
> On 28/06/12 14:38, Mike Stump wrote:
>>
>> On Jun 28, 2012, at 1:28 AM, Matthew Gretton-Dann
>
>> <matthew.gretton-d...@arm.com> wrote:
>>>
>>> On 27/06/12 21:35, Andrew Pinski wrote:
>>>>
>>>> On Wed, Jun 27, 2012 at 3:33 AM, Matthew Gretton-Dann
>>>> <matthew.gretton-d...@arm.com> wrote:
>>>>>
>>>>> All,
>>>>>
>>>>> This patch enables the dump-noaddr test to work in out-of-build-tree
>>>>> testing.
>>>
>>> [snip]
>>>>
>>>>
>>>> I created a much simpler patch which I have been meaning to submit.
>>>> I attached it for reference.
>>>>
>>>>
>>>> Thanks,
>>>> Andrew Pinski
>>>>
>>>> ChangeLog:
>>>> * testsuite/gcc.c-torture/unsorted/dump-noaddr.x (dump_compare): Use
>>>> an absolute dump base instead of a relative one.
>>>>
>>>> Index: gcc.c-torture/unsorted/dump-noaddr.x
>>>> ===================================================================
>>>> --- gcc.c-torture/unsorted/dump-noaddr.x (revision 61452)
>>>> +++ gcc.c-torture/unsorted/dump-noaddr.x (revision 61453)
>>>> @@ -11,10 +11,10 @@ proc dump_compare { src options } {
>>>> foreach option $option_list {
>>>> file delete -force dump1
>>>> file mkdir dump1
>>>> - c-torture-compile $src "$option $options -dumpbase dump1/$dumpbase
>>>> -DMASK=1 -x c --param ggc-min-heapsize=1 -fdump-ipa-all -fdump-rtl-all
>>>> -fdump-tree-all -fdump-noaddr"
>>>> + c-torture-compile $src "$option $options -dumpbase
>>>> [pwd]/dump1/$dumpbase -DMASK=1 -x c --param ggc-min-heapsize=1
>>>> -fdump-ipa-all -fdump-rtl-all -fdump-tree-all -fdump-noaddr"
>>>> file delete -force dump2
>>>> file mkdir dump2
>>>> - c-torture-compile $src "$option $options -dumpbase dump2/$dumpbase
>>>> -DMASK=2 -x c -fdump-ipa-all -fdump-rtl-all -fdump-tree-all -fdump-noaddr"
>>>> + c-torture-compile $src "$option $options -dumpbase
>>>> [pwd]/dump2/$dumpbase -DMASK=2 -x c -fdump-ipa-all -fdump-rtl-all
>>>> -fdump-tree-all -fdump-noaddr"
>>>> foreach dump1 [lsort [glob -nocomplain dump1/*]] {
>>>> regsub dump1/ $dump1 dump2/ dump2
>>>> set dumptail "gcc.c-torture/unsorted/[file tail $dump1]"
>>>
>>>
>>> What I don't like about this approach is that dump1 and dump2 are
>
>>> created in the current working directory.
>>
>>
>> On vxworks as I recall we did a cd to tmpdir, is that generally true?
>> Also, if one telnets in or sshes into the host under test, the cd is
>> mandatory... as otherwise one would dump turds (that's a technical term)
>> in the home directory which would be very uncool. Maybe a better
>> approach would be to cd to the right place if all the Canadian setups cd,
>> as that then unifies them.
>>
>>> With out of build-tree testing this may not (I believe) be the same as
>>> $tmpdir (where temporaries are normally created). Also the current
>>> directory may already contain directories/files called dump1 or dump2
>>> which will get destroyed by running the
>>
>>
>> The point of the cd was to get to a place where temps can be created
>> freely...
>>
>>> I've not committed my version yet in case I am missing something in my
>>> reasoning above with regards to the relationship between the current
>>> working directory and $tmpdir.
>>
>>
>> So the question would be, does his patch work for you? It was unclear to
>> me if the answer is no.
>
>
> Sorry - the patch works for my use case (build==host), but I was concerned
> over the use of [pwd] vs $tmpdir.
Both will work in the case of build==host. I don't even know if we
really support build!=host testing at all. I have never seen it done
and I have no idea how to control it via dejagnu. Has anyone tested
build!=host recently?
Thanks,
Andrew Pinski
>
>> Oh, wait, I know what I don't like about Andrew's patch, pwd, is that the
>> directory on the target, the host or the build machine? And is that
>> going to the host machine? They are not the same. One needs a directory
>> on the host machine.
>
>
> I don't think this applies to my patch though, so are you still okay for my
> version to go in or is there something else I haven't considered?
>
>
> Thanks,
>
> Matt
>
> --
> Matthew Gretton-Dann
> Principal Engineer, PD Software - Tools, ARM Ltd
>
>
> --
> Matthew Gretton-Dann
> Principal Engineer, PD Software - Tools, ARM Ltd
>
>
