Messages in this thread | | | Date | Thu, 10 Mar 2011 14:11:08 -0800 | From | David Daney <> | Subject | Re: [PATCH 0/2] jump label: update for .39 |
| |
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
| |