From: Denis Vlasenko <vda@ilport.com.ua>
To: Alan Modra <amodra@bigpond.net.au>
Cc: binutils@sourceware.org, Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@osdl.org>,
Gerd Hoffmann <kraxel@suse.de>, Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org,
Chuck Ebbert <76306.1226@compuserve.com>,
binutils@sources.redhat.com
Subject: Re: as bug (was: Re: smp/up alternatives crash when CONFIG_HOTPLUG_CPU)
Date: Fri, 5 May 2006 16:13:24 +0300 [thread overview]
Message-ID: <200605051613.24704.vda@ilport.com.ua> (raw)
In-Reply-To: <20060505122029.GB11597@bubble.grove.modra.org>
On Friday 05 May 2006 15:20, Alan Modra wrote:
> On Fri, May 05, 2006 at 11:45:54AM +0300, Denis Vlasenko wrote:
> >
> > .section .smp_altinstr_replacement,"awx"
> > .section .sched.text,"ax",@progbits
> > call _spin_unlock #
> > 661:
> > 2: jle 2b #
> > 662:
> > .section .smp_altinstr_replacement,"awx"
> > .fill 662b-661b,1,0x42
>
> gas should give a better error message here, but really, gas shouldn't
> be expected to assemble this. In essence, you have forward references
> in that expression for the .fill length..
Yes, this should be an error, not warning. It produces miscompiled
object modules.
> Some background: Gas is a single pass assembler. It emits code and
> data into "frags", buffers containing some fixed number of bytes and
> possibly a variable length tail. The variable length part allows
> various features, notably that of variable length instructions. Symbols
> are defined relative to their frags. Until the frag addresses are
> finalized, an expresion involving subtraction of two symbols in
> different frags cannot be evaluated correctly. With the testcase above
> you have exactly that situation. The x86 "jle" instruction can be two
> sizes, either 6 bytes or 2 bytes depending on the offset needed, and gas
> doesn't have the smarts to recognize that the "jle" above is just 2
> bytes. Instead, it assumes a variable size, putting the "jle" in its
> own frag. This means that label "661" and "662" are in separate frags
> with "661" at offset 5 in its frag, and "662" at offset 0.
>
> Since you define the ".smp_altinstr_replacement" section before the
> ".sched.text section", gas tries to finalize ".smp_altinstr_replacement"
> first. When it tries to calculate the fill size using
> (<base addr "662" frag>+<offset "662">)
> - (<base addr "661" frag>+<offset "661">)
> the frag base addresses have not yet been set, and zero is used. ie.
> gas tries to assemble ".fill -5,1,0x42".
Thanks for the explanation.
--
vda
next prev parent reply other threads:[~2006-05-05 13:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-19 9:46 smp/up alternatives crash when CONFIG_HOTPLUG_CPU Ingo Molnar
2006-04-20 5:29 ` Ingo Molnar
2006-04-20 7:45 ` Andi Kleen
2006-04-20 15:14 ` Linus Torvalds
2006-04-20 15:26 ` Ingo Molnar
2006-04-21 7:48 ` Ingo Molnar
2006-05-05 8:40 ` as bug (was: Re: smp/up alternatives crash when CONFIG_HOTPLUG_CPU) Denis Vlasenko
2006-05-05 8:45 ` Denis Vlasenko
2006-05-05 12:20 ` Alan Modra
2006-05-05 13:13 ` Denis Vlasenko [this message]
2006-05-06 3:11 ` Alan Modra
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=200605051613.24704.vda@ilport.com.ua \
--to=vda@ilport.com.ua \
--cc=76306.1226@compuserve.com \
--cc=akpm@osdl.org \
--cc=amodra@bigpond.net.au \
--cc=binutils@sources.redhat.com \
--cc=binutils@sourceware.org \
--cc=kraxel@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@osdl.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