lkml.org 
[lkml]   [2011]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 0/2] jump label: update for .39
From
Date
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?

-- Steve





\
 
 \ /
  Last update: 2011-03-10 22:45    [W:0.181 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site