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 > >