On 18/01/2011 06:50, David Miller wrote:
From: David Millerda...@davemloft.net
Date: Mon, 17 Jan 2011 16:37:09 -0800 (PST)
So we do end up seeing the R_SPARC_LO10 + R_SPARC_13 sequences in the
final module object.
Therefore, we really should handle R_SPARC_13 in the sparc module loader.
On Tue, 2011-01-18 at 10:52 +, Richard Mortimer wrote:
On 18/01/2011 06:50, David Miller wrote:
From: David Millerda...@davemloft.net
Date: Mon, 17 Jan 2011 16:37:09 -0800 (PST)
So we do end up seeing the R_SPARC_LO10 + R_SPARC_13 sequences in the
final module object.
From: Richard Mortimer ri...@oldelvet.org.uk
Date: Tue, 18 Jan 2011 13:23:14 +
To close this off as a non-issue as far as my boot failures are
concerned I did some further checking and objdump is displaying
R_SPARC_OLO10 as two separate entries. I checked the scsi_mod.ko binary
and found
From: David Miller da...@davemloft.net
Date: Tue, 18 Jan 2011 13:00:27 -0800 (PST)
I'll look into fixing binutils so that it properly reports the
correct R_SPARC_OLO10 relocation in dumps. There really is no
excuse for what it's currently doing. In fact, I think this
quirk has sent me on
On Mon, 2011-01-17 at 10:22 +, Richard Mortimer wrote:
On Sun, 2011-01-16 at 22:07 -0800, David Miller wrote:
From: David Miller da...@davemloft.net
Date: Sat, 15 Jan 2011 21:17:22 -0800 (PST)
I think the problem we have here is that the _ftrace_events section is
not aligned
From: Richard Mortimer ri...@oldelvet.org.uk
Date: Mon, 17 Jan 2011 19:46:21 +
As an example from drivers/scsi/scsi_error.c function scsi_eh_wakeup().
This has relocation records of
...
2be4 R_SPARC_LO10 __tracepoint_scsi_eh_wakeup
2be4 R_SPARC_13
On Mon, 2011-01-17 at 13:02 -0800, David Miller wrote:
From: Richard Mortimer ri...@oldelvet.org.uk
Date: Mon, 17 Jan 2011 19:46:21 +
As an example from drivers/scsi/scsi_error.c function scsi_eh_wakeup().
This has relocation records of
...
2be4 R_SPARC_LO10
From: Richard Mortimer ri...@oldelvet.org.uk
Date: Mon, 17 Jan 2011 23:34:03 +
However the same R_SPARC_13 also exists in scsi_mod.ko. It exists in the
original Debian 2.6.37-trunk-sparc64 version and in my current build of
the same with the 8 byte alignment for _trace_events.
...
Thanks
From: Richard Mortimer ri...@oldelvet.org.uk
Date: Mon, 17 Jan 2011 23:34:03 +
I guess that points towards the binutils linker not doing the correct
thing.
Ok, it is in fact doing the correct thing.
I'm really surprised we never hit this before in all of these years
:-) I guess we've
On 18/01/2011 00:37, David Miller wrote:
From: Richard Mortimerri...@oldelvet.org.uk
Date: Mon, 17 Jan 2011 23:34:03 +
I guess that points towards the binutils linker not doing the correct
thing.
Ok, it is in fact doing the correct thing.
I'm really surprised we never hit this before
From: David Miller da...@davemloft.net
Date: Mon, 17 Jan 2011 16:37:09 -0800 (PST)
So we do end up seeing the R_SPARC_LO10 + R_SPARC_13 sequences in the
final module object.
Therefore, we really should handle R_SPARC_13 in the sparc module loader.
Ok, I now feel like I'm hallucinating.
11 matches
Mail list logo
