Message-ID: <4D790A13.4060705@caviumnetworks.com>
Date:	Thu, 10 Mar 2011 09:27:47 -0800
From:	David Daney <ddaney@...iumnetworks.com>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Jason Baron <jbaron@...hat.com>, peterz@...radead.org,
	hpa@...or.com, mingo@...e.hu, tglx@...utronix.de,
	andi@...stfloor.org, roland@...hat.com, rth@...hat.com,
	masami.hiramatsu.pt@...achi.com, fweisbec@...il.com,
	avi@...hat.com, davem@...emloft.net, sam@...nborg.org,
	michael@...erman.id.au, linux-kernel@...r.kernel.org,
	Ralf Baechle <ralf@...ux-mips.org>
Subject: Re: [PATCH 0/2] jump label: update for .39

On 03/10/2011 07:38 AM, Steven Rostedt wrote:
> On Thu, 2011-03-10 at 09:11 -0500, Mathieu Desnoyers wrote:
>> * Steven Rostedt (rostedt@...dmis.org) wrote:
>>> On Wed, 2011-03-09 at 15:47 -0500, Jason Baron wrote:
>>>> Hi,
>>>>
>>>> Re-fresh of updates against latest -tip tree.
>>>
>>> Thanks Jason,
>>>
>>> I started looking at them, I should have comments tomorrow (if I have
>>> any comments ;)
>>>
>>>>
>>>> I've tried to split this update up somewhat, but I've only succeeded to split
>>>> out the dynamic debug bits. The interface changes and re-write are quite
>>>> intertwined.
>>>>
>>>> I believe this update should address all the comments from the previous posting
>>>> except for Mathieu's request for a section of jump label pointers that point to
>>>> the jump label structures (since the compiler might leave gaps in the jump label
>>>> structures).
>>>
>>> The jump label structures is a list of 3 pointers, correct? I doubt that
>>> gcc would place any holes in it as they are all aligned by natural word
>>> size.
>>>
>>
>> Hi Steven,
>>
>> Can you explain what would prevent gcc from aligning these 3 pointers
>> (total of 24 bytes on 64-bit architectures) on 32-bytes ?

I can:

http://www.x86-64.org/documentation/abi.pdf Section 3.1.2:

    Aggregates and Unions

    Structures and unions assume the alignment of their most strictly
    aligned component. Each member is assigned to the lowest
    available offset with the appropriate alignment. The size of any
    object is always a multiple of the object‘s alignment.

    An array uses the same alignment as its elements, except that a
    local or global array variable of length at least 16 bytes or a C99
    variable-length array variable always has alignment of at least 16
    bytes.

    Structure and union objects can require padding to meet size and
    alignment constraints. The contents of any padding is undefined.

I don't think it is explicitly stated, but it is also true that the size 
is the smallest value that meets the above constraints.


>> Also, could
>> you point out what would refrain the linker from aligning the start of
>> object sections on the next 32-bytes (thus power of two) address
>> multiple ?
>

The rules of the ABI are quite specific.  It would be a toolchain bug if 
this were messed up.



> Maybe it would be just easier to add another long ;)

Maybe we should audit all the data structures in the entire kernel and 
add manual padding to power of 2 boundaries.

>
> Seriously, it would. Then it would be 32 bytes on 64bit and 16 bytes on
> 32bit. Then I guess we can have our guarantee without doing a large
> change to have this indirect pointer and still waste sizeof(long) bytes
> in having it.
>
> Just insert a long "Reserved" word.
>

I disagree.  Wasting memory to work around non-existent hypothetical 
bugs seems wrong to me.

David Daney
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists