On 18/04/16 20:17, Alex Bennée wrote: > Sergey Fedorov <serge.f...@gmail.com> writes: > >> On 18/04/16 17:09, Alex Bennée wrote: >>> Sergey Fedorov <sergey.fedo...@linaro.org> writes: >>>> diff --git a/cpu-exec.c b/cpu-exec.c >> (snip) >>>> @@ -507,14 +510,12 @@ int cpu_exec(CPUState *cpu) >>>> } >>>> tb_lock(); >>>> tb = tb_find_fast(cpu); >>>> - /* Note: we do it here to avoid a gcc bug on Mac OS X when >>>> - doing it in tb_find_slow */ >>> Is this still true? Would it make more sense to push the patching down >>> to the gen_code? >> This comment comes up to the commit: >> >> commit 1538800276aa7228d74f9d00bf275f54dc9e9b43 >> Author: bellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162> >> Date: Mon Dec 19 01:42:32 2005 +0000 >> >> workaround for gcc bug on PowerPC >> >> >> It was added more than ten years ago. Anyway, now this code is here not >> because of the bug: we need to reset 'next_tb' which is a local variable >> in cpu_exec(). Personally, I don't think it would be neater to hide it >> into gen_code(). Do you have some thoughts on how we could benefit from >> doing so? BTW, I had a feeling that it may be useful to reorganize >> cpu_exec() a bit, although I don't have a solid idea of how to do this >> so far. > I'm mainly eyeing the tb_lock/unlock which would be nice to push further > down the call chain if we can, especially if the need to lock > tb_find_fast can be removed later on.
Yes, it would be nice to possibly have all tb_lock/unlock() calls (or at least their pairs) in the same block. There is a lot to be thought over :) Kind regards, Sergey
