Re: [PATCH 0/2] jump label: update for .39

From: David Daney
Date: Thu Mar 10 2011 - 17:11:21 EST


On 03/10/2011 01:42 PM, Steven Rostedt wrote:
On Thu, 2011-03-10 at 16:22 -0500, Mathieu Desnoyers wrote:

Anyway, I think the best thing for now is to have Jason add
the .align(sizeof(long)) in the inline assembly for all locations and be
done with it.

You seem to be contradicting yourself here. I'm concerned about having
"structures" of a size not power of two. Can we simply either

But we don't have structures. We have data that has been allocated in
assembly. Come to think of it, it may be best to keep these as
".align 4".



- Add a padding element at the end
or
- use .align 4*sizeof(long) at the beginning

to make sure the linker won't put any holes when it puts objects
together ?


The linker should be dumb and not trying to "optimize", because it has
no idea what the content is. If anything, it should try to compact
things as best as possible, with the exception of keeping things
naturally word aligned. If you added even ".align(4)" on a 64bit system,
the linker should be trying to keep everything packed.

If I get time, I could look at the linker code to see exactly what it
does, but adding holes into sections that are naturally word align seems
more like a bug in the linker than a problem that we need to deal with.

The only issue I could fathom, is if gcc added its own padding in a
section. That is, when it created the __jump_table section with one
element, it added another 4/8 bytes to make the section size a power of
two. Maybe that is a true issue, maybe not. It would seems stupid to do
so IMHO, because when you get to bigger numbers, the aligning a power of
2 can get much bigger. But perhaps it does it for small power of 2s?


GCC on x86_64 likes to align its data with .align 16:
-------------------------------
$ cat jl.c

struct foo {
long a;
long b;
long c;
};

struct foo bar = {1,2,3};

$ gcc -O3 -S jl.c
$ cat jl.s
.file "jl.c"
.globl bar
.data
.align 16
.type bar, @object
.size bar, 24
bar:
.quad 1
.quad 2
.quad 3
.ident "GCC: (GNU) 4.4.4 20100630 (Red Hat 4.4.4-10)"
.section .note.GNU-stack,"",@progbits
----------------------------------

But that shouldn't matter because we only emit data to the __jump_table section from asm().

GCC is getting a reference to that table (array of structures really) from a global variable, I don't see how it can violate the ABI in this case.


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