> On 2026-03-08 10:28, Jan Hubicka wrote: > > > From: Dhruv Chawla <[email protected]> > > > > > > This is a partial fix for PR124075 which forces perf record to write > > > the > > > profile out to perf.data. This is required because I noticed on both > > > aarch64 and x86 that it was writing out the profile to stdout at > > > times, > > > which would cause profile information to be dropped. This did not fail > > > in the various create_fdas_for_* targets because they would only try > > > and > > > access the perf profiles if they existed at their paths. > > > > > > Further work for this patch is to plumb the PERF_DATA make variable > > > into > > > the perf record invocation, but that is a stage 1 thing. > > > > > > Autoprofilebootstrapped and regtested on aarch64-linux-gnu. > > > > > > Signed-off-by: Dhruv Chawla <[email protected]> > > > > > > gcc/ChangeLog: > > > PR gcov-profile/124075 > > > * config/aarch64/gcc-auto-profile: Add "-o perf.data" to perf > > > record invocation. > > > * config/i386/gcc-auto-profile: Likewise. > > > > I have similar change in my tree for some time, so i can do > > profiledbootstraps without getting perf data accidentlly streamed into > > redirected stdout/stderr. I do it in the Makefile.ac instead of > > perf.data. > > > > Again I would like Andy to have chance to comment, but the change looks > > OK to me. > > I don't think I've ever seen that issue. You get the perf.data binary > blob in the output? It shouldn't have anything to do with redirection or > not. > > -o perf.data is default.
For me perf record ls 2>&1 | tee out outputs the perf data to out. This also happens with make autoprofiledboostrap 2>&1 | tee out and always surprises me Honza > > the only way I could think of this happening is when the passed command > has an -o /dev/stdout or -o /dev/stderr and maybe perf misparses it somehow > (but normally it stops option parsing at the first command name), but then > normally perf uses the last option as the winner, so you should still > see the same output. > > If that's the case the correct fix would be to add a "--" before the "$@" to > separate the perf options from others. > > If you want to change the output it would probably be better to pass in a > name with > the PID in it (perf.data.$$) from the caller, this would allow multiple > profiles > steps in the same directory eventually (but I think the profile process only > runs > once per directory atm) > > -Andi
