On 11/25/24 13:47, Pierrick Bouvier wrote:
On 11/25/24 09:05, Peter Maydell wrote:
On Mon, 25 Nov 2024 at 16:48, Pierrick Bouvier
wrote:
Before sending the a series removing gcc_struct and editing the
documentation, do we all agree here it's the right move forward?
If yes, should we apply this
On 11/25/24 09:05, Peter Maydell wrote:
On Mon, 25 Nov 2024 at 16:48, Pierrick Bouvier
wrote:
Before sending the a series removing gcc_struct and editing the
documentation, do we all agree here it's the right move forward?
If yes, should we apply this to 9.2 release?
I would prefer not to put
On Mon, 25 Nov 2024 at 16:48, Pierrick Bouvier
wrote:
> Before sending the a series removing gcc_struct and editing the
> documentation, do we all agree here it's the right move forward?
> If yes, should we apply this to 9.2 release?
I would prefer not to put it into the 9.2 release -- it's one
o
On 11/24/24 23:00, Paolo Bonzini wrote:
On Sun, Nov 24, 2024 at 9:23 PM Pierrick Bouvier
wrote:
* there is no pushback against clang support, there is pushback
against asking for a change without understanding the problem
Thanks for taking time to share more insights about it.
As an aside,
Thanks everyone for your valuable feedback on this, and taking time to
give more rationale about the previous position you had.
On 11/25/24 03:19, Thomas Huth wrote:
So fine for me if we allow compiling with Clang on Windows now, but we
should make sure to avoid that those problems are sneakin
On 11/25/24 06:04, Richard Henderson wrote:
On 11/23/24 18:21, Pierrick Bouvier wrote:
After thinking about it, a simple, exhaustive and reliable way to find this type
information is the debug (dwarf) info.
By compiling qemu binaries with --enable-debug, and extracting info using
llvm-dwarfdump
On 11/23/24 18:21, Pierrick Bouvier wrote:
After thinking about it, a simple, exhaustive and reliable way to find this type
information is the debug (dwarf) info.
By compiling qemu binaries with --enable-debug, and extracting info using llvm-dwarfdump
plus a custom filter [4], we can obtain a te
On 25/11/2024 10.39, Paolo Bonzini wrote:
On Mon, Nov 25, 2024 at 10:34 AM Daniel P. Berrangé wrote:
IMHO we need to have confidence not only in the current state of the code,
but also that we're not going to accidentally regresss it in the future.
This is what the gcc_struct attribute gives us
On Mon, 25 Nov 2024 at 09:39, Paolo Bonzini wrote:
>
> On Mon, Nov 25, 2024 at 10:34 AM Daniel P. Berrangé
> wrote:
> > IMHO we need to have confidence not only in the current state of the code,
> > but also that we're not going to accidentally regresss it in the future.
> > This is what the gcc
On Mon, Nov 25, 2024 at 10:34 AM Daniel P. Berrangé wrote:
> IMHO we need to have confidence not only in the current state of the code,
> but also that we're not going to accidentally regresss it in the future.
> This is what the gcc_struct attribute gives us confidence in.
Yes, as you say below
On Mon, Nov 25, 2024 at 08:00:00AM +0100, Paolo Bonzini wrote:
> On Sun, Nov 24, 2024 at 9:23 PM Pierrick Bouvier
> wrote:
> > -mms-bitfields is already the (silent) gcc default on windows, to mimic
> > MSVC behaviour. Yes, it would be preferable to use this default and
> > gcc_struct attribute, b
On 24/11/2024 21.23, Pierrick Bouvier wrote:
On 11/24/24 04:10, Paolo Bonzini wrote:
On 11/24/24 01:21, Pierrick Bouvier wrote:
After thinking about it, a simple, exhaustive and reliable way to find
this type information is the debug (dwarf) info.
By compiling qemu binaries with --enable-debug,
On Sun, Nov 24, 2024 at 9:23 PM Pierrick Bouvier
wrote:
> > This one unfortunately shows why the global change is wrong. The size
> > of _GIOChannel must match between glib and QEMU, otherwise you have an
> > ABI mismatch.
>
> In the codebase, we always use this type as an opaque type (through
>
On 24/11/2024 13.28, Philippe Mathieu-Daudé wrote:
On 24/11/24 01:21, Pierrick Bouvier wrote:
Hi all,
After thinking about it, a simple, exhaustive and reliable way to find
this type information is the debug (dwarf) info.
By compiling qemu binaries with --enable-debug, and extracting info us
On 11/24/24 04:28, Philippe Mathieu-Daudé wrote:
On 24/11/24 01:21, Pierrick Bouvier wrote:
Hi all,
After thinking about it, a simple, exhaustive and reliable way to find
this type information is the debug (dwarf) info.
By compiling qemu binaries with --enable-debug, and extracting info
usin
On 11/24/24 04:10, Paolo Bonzini wrote:
On 11/24/24 01:21, Pierrick Bouvier wrote:
After thinking about it, a simple, exhaustive and reliable way to find
this type information is the debug (dwarf) info.
By compiling qemu binaries with --enable-debug, and extracting info
using llvm-dwarfdump plus
On 24/11/24 01:21, Pierrick Bouvier wrote:
Hi all,
After thinking about it, a simple, exhaustive and reliable way to find
this type information is the debug (dwarf) info.
By compiling qemu binaries with --enable-debug, and extracting info
using llvm-dwarfdump plus a custom filter [4], we can
On 11/24/24 01:21, Pierrick Bouvier wrote:
After thinking about it, a simple, exhaustive and reliable way to find
this type information is the debug (dwarf) info.
By compiling qemu binaries with --enable-debug, and extracting info
using llvm-dwarfdump plus a custom filter [4], we can obtain a te
patibility with MSVC, so
it's safe to enable this.
Before pushing the change again in a new series, I would like to get
feedback from the concerned developers, and hope it can convince you
this time it's a better approach than what we have.
As a side effect of all this, it will unlock
19 matches
Mail list logo