From: David Miller <davem@davemloft.net>
To: richm@oldelvet.org.uk
Cc: 609371@bugs.debian.org, ben@decadent.org.uk,
sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org,
rostedt@goodmis.org, fweisbec@gmail.com, mingo@redhat.com,
Jesper.Nilsson@axis.com, jeffm@suse.com
Subject: Re: Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
Date: Sun, 16 Jan 2011 22:07:55 -0800 (PST) [thread overview]
Message-ID: <20110116.220755.179947617.davem@davemloft.net> (raw)
In-Reply-To: <20110115.211722.39173519.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sat, 15 Jan 2011 21:17:22 -0800 (PST)
[ Please, everyone, retain the full CC: on all replies, thanks. Some
people are replying only into the debian bug alias, and that loses
information and exposure for fixing this bug. ]
> I think the problem we have here is that the _ftrace_events section is
> not aligned sufficiently. That ".align 4" mnemonic is a good indication
> of this. It should at least "8" on sparc64.
I did some more research.
Although I've seen commentary to the contrary, in fact using a too-small
__attribute__((aligned())) directive will lower the alignment of data
members, and yes that means it will lower the alignemnt to be below the
natural and required alignment for the given type.
So if you have, on 64-bit:
struct foo {
void *bar;
};
static struct foo test __attribute__((__aligned__(4)));
The compiler will emit "test" with 4-byte alignment into the data
section, even though 8-byte alignment is required for "test.bar"
Assuming we wanted that to actually happen, the GCC manual is very
explicit to state that in order for this to work, such down-aligned
data structures must also use the "packed" attribute.
I think we want none of this, and I think we should elide the align
directives entirely, or at least fix them so we don't get unaligned
stuff on 64-bit.
Ugh, and I just noticed that include/linux/klist.h does this fixed
alignment of "4" too, where is this stuff coming from? It's
wrong on 64-bit, at best. But I can't see the impetus behind doing
this at all in the first place.
Oh, this is some CRIS thing, because it only byte aligns. See:
commit c0e69a5bbc6fc74184aa043aadb9a53bc58f953b
Author: Jesper Nilsson <Jesper.Nilsson@axis.com>
Date: Wed Jan 14 11:19:08 2009 +0100
klist.c: bit 0 in pointer can't be used as flag
That's where the klist one comes from.
The ftrace ones come from:
commit 86c38a31aa7f2dd6e74a262710bf8ebf7455acc5
Author: Jeff Mahoney <jeffm@suse.com>
Date: Wed Feb 24 13:59:23 2010 -0500
tracing: Fix ftrace_event_call alignment for use with gcc 4.5
We really can't handle this that way, it's going to break stuff
on 64-bit systems at the very least.
How about we use __BIGGEST_ALIGNMENT__ or something arch-defined value
instead?
next prev parent reply other threads:[~2011-01-17 6:07 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20110113.155700.102679408.davem@davemloft.net>
[not found] ` <4D302B2F.7030108@oldelvet.org.uk>
[not found] ` <4D3074FE.3030707@oldelvet.org.uk>
2011-01-16 5:17 ` David Miller
2011-01-16 14:17 ` Richard Mortimer
2011-01-16 19:39 ` David Miller
2011-01-17 14:11 ` Steven Rostedt
2011-01-17 14:37 ` Bastian Blank
2011-01-17 19:35 ` Mathieu Desnoyers
2011-01-18 6:36 ` David Miller
2011-01-18 5:34 ` David Miller
2011-01-18 6:00 ` David Miller
2011-01-18 6:08 ` David Miller
2011-01-18 16:46 ` Mathieu Desnoyers
2011-01-18 17:33 ` Steven Rostedt
2011-01-18 18:16 ` Steven Rostedt
2011-01-18 18:26 ` Steven Rostedt
2011-01-18 20:13 ` Mathieu Desnoyers
2011-01-18 20:22 ` Steven Rostedt
2011-01-19 5:08 ` Mathieu Desnoyers
2011-01-19 5:16 ` David Miller
2011-01-19 15:10 ` Mathieu Desnoyers
2011-01-19 16:14 ` Sam Ravnborg
2011-01-19 16:18 ` Mathieu Desnoyers
2011-01-19 6:32 ` David Miller
2011-01-19 7:20 ` David Miller
2011-01-19 15:33 ` Mathieu Desnoyers
2011-01-19 21:40 ` David Miller
2011-01-19 22:00 ` Steven Rostedt
2011-01-19 22:09 ` David Miller
2011-01-19 22:21 ` Mathieu Desnoyers
2011-01-19 22:23 ` David Miller
2011-01-19 22:32 ` Sam Ravnborg
2011-01-19 22:34 ` Mathieu Desnoyers
2011-01-19 22:13 ` Mathieu Desnoyers
2011-01-19 22:21 ` David Miller
2011-01-19 22:33 ` Mathieu Desnoyers
2011-01-20 0:41 ` David Miller
2011-01-21 0:04 ` Mathieu Desnoyers
2011-01-21 18:06 ` Richard Mortimer
2011-01-21 18:52 ` Mathieu Desnoyers
2011-01-21 19:15 ` Mathieu Desnoyers
2011-01-21 20:14 ` Richard Mortimer
2011-01-21 20:40 ` Mathieu Desnoyers
2011-01-21 22:50 ` Richard Mortimer
2011-01-22 18:42 ` Richard Mortimer
2011-01-22 18:53 ` Mathieu Desnoyers
2011-01-19 15:46 ` Steven Rostedt
2011-01-19 16:15 ` Mathieu Desnoyers
2011-01-19 18:13 ` Steven Rostedt
2011-01-19 18:20 ` Mathieu Desnoyers
2011-01-19 21:44 ` David Miller
2011-01-19 22:15 ` Mathieu Desnoyers
2011-01-19 22:22 ` David Miller
2011-01-19 15:11 ` Mathieu Desnoyers
2011-01-19 15:27 ` Richard Mortimer
2011-01-17 6:07 ` David Miller [this message]
2011-01-17 9:05 ` Jesper Nilsson
2011-02-01 5:11 ` David Miller
2011-02-01 10:03 ` Jesper Nilsson
2011-01-17 10:22 ` Richard Mortimer
2011-01-17 14:15 ` Steven Rostedt
2011-01-18 6:35 ` David Miller
2011-01-18 17:30 ` Steven Rostedt
2011-01-17 19:46 ` R_SPARC_13 (Re: Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36) Richard Mortimer
2011-01-17 21:02 ` R_SPARC_13 David Miller
2011-01-17 23:34 ` R_SPARC_13 Richard Mortimer
2011-01-18 0:18 ` R_SPARC_13 David Miller
2011-01-18 0:37 ` R_SPARC_13 David Miller
2011-01-18 1:28 ` R_SPARC_13 Richard Mortimer
2011-01-18 6:50 ` R_SPARC_13 David Miller
2011-01-18 10:52 ` R_SPARC_13 Richard Mortimer
2011-01-18 13:23 ` R_SPARC_13 Richard Mortimer
2011-01-18 21:00 ` R_SPARC_13 David Miller
2011-01-19 4:12 ` R_SPARC_13 David Miller
2011-01-17 14:39 ` Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36 Bernhard R. Link
2011-01-18 5:24 ` David Miller
2011-01-18 9:26 ` Jesper Nilsson
2011-01-18 6:27 ` David Miller
2011-01-18 17:05 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110116.220755.179947617.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=609371@bugs.debian.org \
--cc=Jesper.Nilsson@axis.com \
--cc=ben@decadent.org.uk \
--cc=fweisbec@gmail.com \
--cc=jeffm@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=richm@oldelvet.org.uk \
--cc=rostedt@goodmis.org \
--cc=sparclinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®