[Qemu-devel] Re: [PATCH 2/6] qemu fixes

[Qemu-devel] Re: [PATCH 2/6] qemu fixes

[Jan Kiszka]

Christoph Egger wrote:
> Hi,
> 
> This is a series of four patches which improve support
> for qemu on NetBSD.
> 
> Attached patch fixes warnings in the i386 specific part.
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> 

Except for ss* in [copy, paste, sigh]...

> @@ -2275,8 +2275,8 @@
>                              int shift, int next_eip_addend)
>  {
>      int new_stack, i;
> -    uint32_t e1, e2, cpl, dpl, rpl, selector, offset, param_count;
> -    uint32_t ss, ss_e1, ss_e2, sp, type, ss_dpl, sp_mask;
> +    uint32_t e1 = 0, e2 = 0, cpl, dpl, rpl, selector, offset, param_count;
> +    uint32_t ss = 0, ss_e1 = 0, ss_e2 = 0, sp, type, ss_dpl, sp_mask;
>      uint32_t val, limit, old_sp_mask;
>      target_ulong ssp, old_ssp, next_eip;
>  

I have a better patch here that fixes the root of gcc's confusion:
missing noreturn instrumentation. The detection of the initialization of
ss* variables falls into the category "gcc isn't smart enough", and one
may discuss if we should handle it or wait for gcc getting smarter. BTW,
this patch is not BSD specific but gcc4 related.

Nevertheless, warning reduction patches are generally welcome IMHO!

Jan

Re: [Qemu-devel] Re: [PATCH 2/6] qemu fixes

[Christoph Egger]

On Friday 28 November 2008 12:44:33 you wrote:
> Christoph Egger wrote:
> > Hi,
> >
> > This is a series of four patches which improve support
> > for qemu on NetBSD.
> >
> > Attached patch fixes warnings in the i386 specific part.
> >
> > Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
>
> Except for ss* in [copy, paste, sigh]...
>
> > @@ -2275,8 +2275,8 @@
> >                              int shift, int next_eip_addend)
> >  {
> >      int new_stack, i;
> > -    uint32_t e1, e2, cpl, dpl, rpl, selector, offset, param_count;
> > -    uint32_t ss, ss_e1, ss_e2, sp, type, ss_dpl, sp_mask;
> > +    uint32_t e1 = 0, e2 = 0, cpl, dpl, rpl, selector, offset,
> > param_count; +    uint32_t ss = 0, ss_e1 = 0, ss_e2 = 0, sp, type,
> > ss_dpl, sp_mask; uint32_t val, limit, old_sp_mask;
> >      target_ulong ssp, old_ssp, next_eip;
>
> I have a better patch here that fixes the root of gcc's confusion:
> missing noreturn instrumentation. The detection of the initialization of
> ss* variables falls into the category "gcc isn't smart enough", and one
> may discuss if we should handle it or wait for gcc getting smarter. BTW,
> this patch is not BSD specific but gcc4 related.

Well, go ahead then.

> Nevertheless, warning reduction patches are generally welcome IMHO!

Nice to hear.

Christoph

-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy