From: David Miller
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 wild goose chases
From: Richard Mortimer
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 the appropriate El
On Tue, 2011-01-18 at 10:52 +, Richard Mortimer wrote:
>
> On 18/01/2011 06:50, David Miller wrote:
> > From: David Miller
> > 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.
> >>
> >> Therefor
On 18/01/2011 06:50, David Miller wrote:
From: David Miller
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
From: David Miller
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.
davem@sunset:~/src/
On 18/01/2011 00:37, David Miller wrote:
From: Richard Mortimer
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
From: Richard Mortimer
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 simply never hit this ki
From: Richard Mortimer
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 for the info Richa
On Mon, 2011-01-17 at 13:02 -0800, David Miller wrote:
> From: Richard Mortimer
> 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_
From: Richard Mortimer
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*ABS*+0x000
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
> > 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 sufficiently.
11 matches
Mail list logo