From: Frank Rowand <frank_rowand@mvista.com>
To: Michael Schmitz <schmitz@zirkon.biophys.uni-duesseldorf.de>
Cc: jaf <jaf@lcsaudio.com>,
Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de>,
linuxppc-dev@lists.linuxppc.org, jeffk@jdkoftinoff.com
Subject: Re: Having linking problems with atomic_inc(), atomic_dec_and_test()in user app, help!
Date: Fri, 04 Jan 2002 11:50:44 -0800 [thread overview]
Message-ID: <3C360794.E264BDFE@mvista.com> (raw)
In-Reply-To: Pine.LNX.4.10.10201041821170.19962-100000@zirkon.biophys.uni-duesseldorf.de
Michael Schmitz wrote:
>
> > >> Also, what does "relocation truncated to fit: R_PPC_REL24
> > atomic_inc(atomic_t
> > >> *)" mean?
> > >
> > >About as much as 'unresolved external reference'. atomic_inc isn't
> > defined
> > >in the scope of your code. Look at the kernel headers; it might be
> > inside
> > >#ifdef __KRENEL__ (actually it is).
> >
> > I see... when I wrote the code using Red Hat, this was not the case. I
> > assumed
> > things would be similar under all Linuxes... apparently a bad
> > assumption.
>
> It's a kernel or libc header issue - what kernel/libc version was that
> on? As far as I can see atomic operations are exported to user programs
> except on ppc (not ppc64), mips*, arm and sparc. At least in one case it's
> obvious why: MIPS needs to protect against interrupts to guarantee
> atomicity.
> Another corner case seems to be IBM 405 processors that use what I think
> is a privileged instruction as well in order to work around a hardware
> bug.
The dcbt instruction (the workaround) should not be privileged.
< stuff deleted >
-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-01-04 19:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-04 17:00 Having linking problems with atomic_inc(), atomic_dec_and_test() in user app, help! jaf
2002-01-04 17:44 ` Michael Schmitz
2002-01-04 19:04 ` Tom Rini
2002-01-04 19:50 ` Frank Rowand [this message]
2002-01-04 19:52 ` Having linking problems with atomic_inc(), atomic_dec_and_test()in " Michael Schmitz
2002-01-04 18:33 ` Having linking problems with atomic_inc(), atomic_dec_and_test() in " Kevin B. Hendricks
2002-01-04 18:57 ` Kevin B. Hendricks
-- strict thread matches above, loose matches on Subject: below --
2002-01-04 3:24 Jeremy Friesner
2002-01-04 11:46 ` Jerry Van Baren
2002-01-04 12:57 ` Benjamin Herrenschmidt
2002-01-04 14:18 ` Michael Schmitz
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=3C360794.E264BDFE@mvista.com \
--to=frank_rowand@mvista.com \
--cc=frowand@mvista.com \
--cc=jaf@lcsaudio.com \
--cc=jeffk@jdkoftinoff.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=schmitz@opal.biophys.uni-duesseldorf.de \
--cc=schmitz@zirkon.biophys.uni-duesseldorf.de \
/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