On 2011-08-25 16:03, Stefan Weil wrote:
> As I wrote in my last mail, I compared all structs without and with
> -mms-bitfields
> using pahole and codiff. The result is in the appended codiff.log.
>
> About 17 structs changed because of -mms-bitfield. This attribute
> modifies not only
> structs wi
On 08/25/2011 09:03 AM, Stefan Weil wrote:
As I wrote in my last mail, I compared all structs without and with
-mms-bitfields
using pahole and codiff. The result is in the appended codiff.log.
About 17 structs changed because of -mms-bitfield. This attribute
modifies not only
structs with bitfie
As I wrote in my last mail, I compared all structs without and with
-mms-bitfields
using pahole and codiff. The result is in the appended codiff.log.
About 17 structs changed because of -mms-bitfield. This attribute
modifies not only
structs with bitfield but also packed structs or structs with
On 08/25/2011 04:36 PM, Peter Maydell wrote:
On 25 August 2011 14:22, Avi Kivity wrote:
> On 08/25/2011 04:13 PM, Jan Kiszka wrote:
>> Packing all structs is not really a good idea, more a last resort.
>
> btw, how are the non-x86s handling this? by trapping and fixuping in the
> kernel?
If
On 25 August 2011 14:22, Avi Kivity wrote:
> On 08/25/2011 04:13 PM, Jan Kiszka wrote:
>> Packing all structs is not really a good idea, more a last resort.
>
> btw, how are the non-x86s handling this? by trapping and fixuping in the
> kernel?
If a structure's packing means it doesn't adhere to t
On 2011-08-25 15:28, Anthony Liguori wrote:
> On 08/25/2011 08:13 AM, Jan Kiszka wrote:
>> On 2011-08-25 15:06, Anthony Liguori wrote:
>>> On 08/25/2011 07:38 AM, Jan Kiszka wrote:
On 2011-08-25 14:02, TeLeMan wrote:
> On Thu, Aug 25, 2011 at 19:04, Jan Kiszka wrote:
>> What a mess.
On 08/25/2011 08:13 AM, Jan Kiszka wrote:
On 2011-08-25 15:06, Anthony Liguori wrote:
On 08/25/2011 07:38 AM, Jan Kiszka wrote:
On 2011-08-25 14:02, TeLeMan wrote:
On Thu, Aug 25, 2011 at 19:04, Jan Kiszka wrote:
What a mess. Do we really have to go through all 257 packed data
structs
in QE
On 08/25/2011 04:13 PM, Jan Kiszka wrote:
>
> So why can't we just #pragma guard all of the slirp bits? Why are we
> doing it on a per data structure basis?
Packing all structs is not really a good idea, more a last resort.
btw, how are the non-x86s handling this? by trapping and fixuping
On 08/25/2011 04:19 PM, Jan Kiszka wrote:
>
> However, I don't like it either, and prefer the
> __attribute__(((gcc_fields)) as well.
Could someone with a Windows environment test if that (or (packed,
gcc_fields)?) makes
struct {
unsigned char a;
unsigned int b;
};
tr
On 2011-08-25 15:15, Avi Kivity wrote:
> On 08/25/2011 04:07 PM, Anthony Liguori wrote:
>> On 08/25/2011 08:02 AM, Avi Kivity wrote:
>>> On 08/25/2011 03:38 PM, Jan Kiszka wrote:
>>
>> What a mess. Do we really have to go through all 257 packed data
structs
>> in QEMU and add th
On 08/25/2011 04:09 PM, Jan Kiszka wrote:
>>
>> We should simply avoid bitfields on externally-defined formats;
>> meanwhile we can use __attribute__((gcc_struct)) and keep using those we
>> have already.
>
> +1
We aren't discussing bitfields anymore but essential unaligned (and
therefore pa
On 08/25/2011 04:07 PM, Anthony Liguori wrote:
On 08/25/2011 08:02 AM, Avi Kivity wrote:
On 08/25/2011 03:38 PM, Jan Kiszka wrote:
>>
>> What a mess. Do we really have to go through all 257 packed data
structs
>> in QEMU and add these MS compat bits to all potentially affected
ones?
> I prefe
On 2011-08-25 15:06, Anthony Liguori wrote:
> On 08/25/2011 07:38 AM, Jan Kiszka wrote:
>> On 2011-08-25 14:02, TeLeMan wrote:
>>> On Thu, Aug 25, 2011 at 19:04, Jan Kiszka wrote:
What a mess. Do we really have to go through all 257 packed data
structs
in QEMU and add these MS compa
On 2011-08-25 15:07, Anthony Liguori wrote:
> On 08/25/2011 08:02 AM, Avi Kivity wrote:
>> On 08/25/2011 03:38 PM, Jan Kiszka wrote:
>>> >>
>>> >> What a mess. Do we really have to go through all 257 packed data
>>> structs
>>> >> in QEMU and add these MS compat bits to all potentially affected
>>>
On 08/25/2011 08:02 AM, Avi Kivity wrote:
On 08/25/2011 03:38 PM, Jan Kiszka wrote:
>>
>> What a mess. Do we really have to go through all 257 packed data
structs
>> in QEMU and add these MS compat bits to all potentially affected ones?
> I prefer to detect -mms-bitfields and remove it in config
On 08/25/2011 07:38 AM, Jan Kiszka wrote:
On 2011-08-25 14:02, TeLeMan wrote:
On Thu, Aug 25, 2011 at 19:04, Jan Kiszka wrote:
What a mess. Do we really have to go through all 257 packed data structs
in QEMU and add these MS compat bits to all potentially affected ones?
I prefer to detect -mm
On 08/25/2011 03:38 PM, Jan Kiszka wrote:
>>
>> What a mess. Do we really have to go through all 257 packed data structs
>> in QEMU and add these MS compat bits to all potentially affected ones?
> I prefer to detect -mms-bitfields and remove it in configure.
Can use -mno-ms-bitfields later t
On 2011-08-25 14:02, TeLeMan wrote:
> On Thu, Aug 25, 2011 at 19:04, Jan Kiszka wrote:
>> On 2011-08-25 03:14, TeLeMan wrote:
>>> On Wed, Aug 24, 2011 at 17:11, Jan Kiszka wrote:
On 2011-08-23 12:49, TeLeMan wrote:
> On Sun, Aug 21, 2011 at 04:00, Stefan Weil wrote:
>> Am 15.08.2011
On Thu, Aug 25, 2011 at 19:04, Jan Kiszka wrote:
> On 2011-08-25 03:14, TeLeMan wrote:
>> On Wed, Aug 24, 2011 at 17:11, Jan Kiszka wrote:
>>> On 2011-08-23 12:49, TeLeMan wrote:
On Sun, Aug 21, 2011 at 04:00, Stefan Weil wrote:
> Am 15.08.2011 08:39, schrieb Jan Kiszka:
>>
>> T
On 2011-08-25 03:14, TeLeMan wrote:
> On Wed, Aug 24, 2011 at 17:11, Jan Kiszka wrote:
>> On 2011-08-23 12:49, TeLeMan wrote:
>>> On Sun, Aug 21, 2011 at 04:00, Stefan Weil wrote:
Am 15.08.2011 08:39, schrieb Jan Kiszka:
>
> The following changes since commit
> 3b6ffe50300f13240e
On Wed, Aug 24, 2011 at 17:11, Jan Kiszka wrote:
> On 2011-08-23 12:49, TeLeMan wrote:
>> On Sun, Aug 21, 2011 at 04:00, Stefan Weil wrote:
>>> Am 15.08.2011 08:39, schrieb Jan Kiszka:
The following changes since commit
3b6ffe50300f13240e1b46420ad05da1116df410:
hw/scsi-bu
On 2011-08-23 12:49, TeLeMan wrote:
> On Sun, Aug 21, 2011 at 04:00, Stefan Weil wrote:
>> Am 15.08.2011 08:39, schrieb Jan Kiszka:
>>>
>>> The following changes since commit
>>> 3b6ffe50300f13240e1b46420ad05da1116df410:
>>>
>>> hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25
On Sun, Aug 21, 2011 at 04:00, Stefan Weil wrote:
> Am 15.08.2011 08:39, schrieb Jan Kiszka:
>>
>> The following changes since commit
>> 3b6ffe50300f13240e1b46420ad05da1116df410:
>>
>> hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25
>> +)
>>
>> are available in the git re
Thanks, pulled.
On Mon, Aug 15, 2011 at 6:39 AM, Jan Kiszka wrote:
> The following changes since commit 3b6ffe50300f13240e1b46420ad05da1116df410:
>
> hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25 +)
>
> are available in the git repository at:
> git://git.kiszka.org/q
Am 15.08.2011 08:39, schrieb Jan Kiszka:
The following changes since commit
3b6ffe50300f13240e1b46420ad05da1116df410:
hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25
+)
are available in the git repository at:
git://git.kiszka.org/qemu.git queues/slirp
Jan Kiszka (1
The following changes since commit 3b6ffe50300f13240e1b46420ad05da1116df410:
hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25 +)
are available in the git repository at:
git://git.kiszka.org/qemu.git queues/slirp
Jan Kiszka (1):
slirp: Fix bit field types in IP
26 matches
Mail list logo
