Hi
----- Original Message -----
> On 07/11/17 12:04, Marc-André Lureau wrote:
> > Hi
> >
> > ----- Original Message -----
> >> On 07/06/17 12:16, Marc-André Lureau wrote:
> >>> Add vmcoreinfo ELF note if vmcoreinfo device is ready.
> >>>
> >>> To help the python script, add a little global vmcoreinfo_gdb
> >>> structure, that is populated with vmcoreinfo_gdb_update().
> >>>
> >>> Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com>
>
> >>> @@ -181,6 +183,7 @@ static void vmcoreinfo_realize(DeviceState *dev,
> >>> Error
> >>> **errp)
> >>> return;
> >>> }
> >>>
> >>> + vmcoreinfo_gdb_helper = VMCOREINFO(dev);
> >>> qemu_register_reset(vmcoreinfo_handle_reset, dev);
> >>> }
> >>>
> >>>
> >>
> >> I guess we don't build QEMU with link-time optimization at the
> >> moment.
> >>
> >> With link-time optimization, I think gcc might reasonably optimize
> >> away the assignment to "vmcoreinfo_gdb_helper", and
> >> "vmcoreinfo_gdb_helper" itself. This is why I suggested "volatile":
> >>
> >> static VMCoreInfoState * volatile vmcoreinfo_gdb_helper;
> >>
> >> Do you think volatile is only superfluous, or do you actively dislike
> >> it for some reason?
> >
> > Yeah, I am not convinced volatile is the best way, but nor is static.
> >
> > Let's export it?
>
> Volatile guarantees that the assignment will take place according to the
> behavior of the "abstract C machine" described by ISO C. From ISO C99,
>
> 6.7.3 Type qualifiers
>
> 6 An object that has volatile-qualified type may be modified in ways
> unknown to the implementation or have other unknown side effects.
> Therefore any expression referring to such an object shall be
> evaluated strictly according to the rules of the abstract machine,
> as described in 5.1.2.3. Furthermore, at every sequence point the
> value last stored in the object shall agree with that prescribed by
> the abstract machine, except as modified by the unknown factors
> mentioned previously. [116] What constitutes an access to an object
> that has volatile-qualified type is implementation-defined.
>
> Footnote 116: A volatile declaration may be used to describe an object
> corresponding to a memory-mapped input/output port or an
> object accessed by an asynchronously interrupting
> function. Actions on objects so declared shall not be
> "optimized out" by an implementation or reordered except
> as permitted by the rules for evaluating expressions.
>
> So basically if you can find the symbol somehow, it will always have the
> right value, due to the volatile qualifier, regardless of the
> optimizations the compiler did.
>
> Internal vs. external linkage ("static" vs. "extern") is a different
> question; it might affect whether you find the symbol at all. IME,
> symbols for objects with internal linkage are preserved, if: (a) you
> don't strip the final binary, and (b) gcc doesn't optimize the variable
> away.
>
> With link-time / full program optimization, gcc is entitled to optimize
> away variables with external linkage too, so "extern" in itself is not
> bulletproof. Volatile is more important.
Ok, you seem confident about this sort of things, I am not, I'll follow you :)
>
> Given volatile, I'm sort of neutral on extern vs. static. However, if
> you make the variable extern, that makes abuse from other source files
> easier. (The variable should only be looked at with gdb.) This is also
> why I originally suggested to limit the scope of even the static
> variable to function scope -- this way abuse would completely be
> prevented (nothing else could access the variable even from the same
> translation unit), and gdb would still find the variable (IME).
How do you access a static inside a function? Gdb can look it up but complains
that it's not in current context.
