All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@baldric.uwo.ca>
To: John David Anglin <dave@hiauly1.hia.nrc.ca>
Cc: dave.anglin@nrc-cnrc.gc.ca, parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] r19 (aka pic-register akak ltp) not restored on entry back to libc from libpthread?
Date: Fri, 19 Sep 2003 13:51:42 -0400	[thread overview]
Message-ID: <20030919175142.GI18225@systemhalted> (raw)
In-Reply-To: <200309191656.h8JGukWJ003212@hiauly1.hia.nrc.ca>

On Fri, Sep 19, 2003 at 12:56:46PM -0400, John David Anglin wrote:
> > Hold your horses here, we made it back into libc but our ltp is still
> > that which we loaded upon entry to libpthread? :(
> 
> That's ok.  It's the responsibility of the libc code to restore ltp
> after a call or exception.  However, as discussed previously, there
> is no restoration after a syscall.  That should be the system's job,
> although I believe you were going to introduce a hack/workaround to
> fix the syscalls that clobber r19.

For all syscalls whose wrappers are pure assembly or __asm(...) I have
placed restorations to follow ABI. This fixed all of the major failures.
It's a bit drastic, but it fixes the issue until I know exactly which
syscall numbers clobber r19. It looks like just fork and it's variants
that stick a return address into PT_REGS's r19. That's a side issue
about optimization though. 

> You need to step through the libc code from the return point in
> libc to see why ltp isn't being restored.  Possibly, libpthread is
> being called by assembly code that doesn't restore ltp.  Normally,
> r19 is restored quite soon after a call.

There should be no assembly code glue between the calls.
What about the gcc optimization where we don't restore r19 if it's not
used between the last call and the return?

mutex_unlock becomes:
__libc_maybe_call (__pthread_mutex_unlock, (m), (*(int *)(m) = 0))

Which is a big monstrosity that looks like it might be casting things
incorrectly for hppa...

===
#if defined _LIBC && defined IS_IN_libpthread
# define __libc_maybe_call(FUNC, ARGS, ELSE) FUNC ARGS
#else
# if defined __PIC__ || (defined _LIBC && defined SHARED)
#  define __libc_maybe_call(FUNC, ARGS, ELSE) \
  (__extension__ ({ __typeof (FUNC) *_fn = (FUNC); \
                    _fn != NULL ? (*_fn) ARGS : ELSE; }))
# else
#  define __libc_maybe_call(FUNC, ARGS, ELSE) \
  (FUNC != NULL ? FUNC ARGS : ELSE)
# endif
#endif
#if defined _LIBC && !defined NOT_IN_libc && defined SHARED
# define __libc_maybe_call2(FUNC, ARGS, ELSE) \
  ({__builtin_expect (__libc_pthread_functions.ptr_##FUNC != NULL, 0) \
    ? __libc_pthread_functions.ptr_##FUNC ARGS : ELSE; })
#else
# define __libc_maybe_call2(FUNC, ARGS, ELSE) __libc_maybe_call
# (__##FUNC, ARGS, ELSE)
#endif
===

I have class, then I'll be back to -E some of the malloc build to see
what this evaluates to and then try to determine if gcc did the right
thing.

c.

  reply	other threads:[~2003-09-19 17:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-19 13:56 [parisc-linux] r19 (aka pic-register akak ltp) not restored on entry back to libc from libpthread? Carlos O'Donell
2003-09-19 16:56 ` John David Anglin
2003-09-19 17:51   ` Carlos O'Donell [this message]
2003-09-19 18:26     ` James Bottomley
2003-09-19 18:55       ` [parisc-linux] r19 (aka pic-register akak ltp) not restored on John David Anglin
2003-09-19 19:28         ` Carlos O'Donell
2003-09-19 20:10           ` John David Anglin
2003-09-21 15:45             ` [parisc-linux] Found the r19 problem! Carlos O'Donell
2003-09-21 16:39               ` [parisc-linux] " John David Anglin
2003-09-21 18:53                 ` Carlos O'Donell
2003-09-21 18:55                   ` Carlos O'Donell
2003-09-21 19:12                     ` John David Anglin
2003-09-21 19:16                       ` Carlos O'Donell
2003-09-21 19:18                   ` John David Anglin

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=20030919175142.GI18225@systemhalted \
    --to=carlos@baldric.uwo.ca \
    --cc=dave.anglin@nrc-cnrc.gc.ca \
    --cc=dave@hiauly1.hia.nrc.ca \
    --cc=parisc-linux@lists.parisc-linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.