[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH] Bug fix for #986241: spell env corre

From: Peter Portante
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH] Bug fix for #986241: spell env correctly
Date: Sun, 22 Apr 2012 22:25:08 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 04/22/2012 09:22 PM, David Gibson wrote:
On Sun, Apr 22, 2012 at 09:56:09PM +0200, Andreas Färber wrote:
Am 20.04.2012 17:44, schrieb Peter Portante:
Signed-off-by: Peter Portante<address@hidden>
Fix itself looks okay, but author, maintainer and qemu-ppc were missing
in CC, and a better commit message would be:

pseries: Fix use of global CPU state

Commit ed120055c7f9b26b5707d3ceabbe5a3f06aaf937 (Implement PAPR VPA
functions for pSeries shared processor partitions) introduced the
register_dtl() function and typo "emv" as name of its argument.
This went unnoticed because the code in that function can access the
global variable "env" so that no build failure resulted.

Fix the argument to read "env". Resolves LP#986241.
Ouch.  Good catch.
Found by playing around with -flto with gcc. Ran into problems with link time common warnings due to register declaration in dyngen-exec.h being included in multiple .c files where they referenced env. Rebuilt with --enabled-tcg-interpretter (which causes dyngen-exec.h to only emit an extern declaration), and ifdef'd out the storage declarations in other .c files, and voila, undefined reference to env from within hw/spapr_hcall.c.

Do folks seen this as a maintenance headache to have a global variable name used as a parameter name in function arguments as well?

Can somebody speak to the history of using a global variable for env state instead of passing it around in function calls? Is this because we could not trust the compiler to keep it in a register between function calls? If so, then do you think it might be worth a look at what the compilers can do to help simplify somewhat complicated code and still maintain the performance? Or was it that env had to be added to so many functions that it became too tedious to maintain?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]