Re: spinlocks() are severely broken in 2.2.X and 2.4.X for modules

[Jeff V. Merkey]

Jamie,

It looks like Andi Klein and I have tracked it down already.  It's a bug
in gas/ld with relocation records for the .text.lock section being
created by he spinlock macro.  The simple solution here is to get rid of
the fancy .text.lock crap and just use simple linear code.  We are doing
some more testing, but I have to tell you, I've gotten over 20,000
emails in the past month from folks downloading NWFS who have built it
and are seeing this problem, so it may be more widespread than just a
few GCC/LD/BINUTILS version mismatches.  And yes, we have run objdump
--reloc and the relocation record is not getting fixed-up the way it
should.

:-)

Jeff

Jamie Lokier wrote:
> 
> Jeff V. Merkey wrote:
> > what gets generated from spinlock.h and GCC in the 2.4.X case is as
> > follows:
> >
> > <NWLockLRU>
> > 0x45a0    mov    0x4(%esp, 1),%edx
> > 0x45a4    pushf
> > 0s45a5    pop    %eax
> > 0x45a6    cli
> > 0x45a7    mov    %eax,0x80(%edx)
> > 0x45ad    lock   decb 0x7C(%edx)
> > 0x45b1    js     0x4639 <ReleaseWaiters+49>    // if the lock fails it
> > jumps to this address is in the function ReleaseWaiters() ????
> > 0x45b7    ret
> 
> May I suggest you use the `--reloc' option to objdump to generate the
> disassembly, which will show the actual address that is jumped to.
> 
> It will still say "0x4639 <ReleaseWaiters+49>", which is misleading
> (blame the disassembler), but it will also add a line saying where the
> instruction really jumps to after the module is loaded and relocated...
> 
> have a nice day,
> -- Jamie