All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@baldric.uwo.ca>
To: parisc-linux@lists.parisc-linux.org
Subject: [parisc-linux] RFC - glibc - patch reivew - 64->32
Date: Fri, 23 Aug 2002 09:16:35 -0400	[thread overview]
Message-ID: <20020823131634.GA3229@systemhalted> (raw)

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

pa,

I've been going through some of the glibc issues that we
have and trying to fix them... or put in a large enough shoe
-horn that the solution fits.

The following are two .dpatch's that I'd like to send to
gotom to get put in for -15 or -16 depending on how much
testing I get done.

The first .dpatch has to do with our jmpbuf implementation,
and the fact that division calculation is not always 
correct. I _think_ this is a solution, but since I'm away
this weekend, I challenge someone to put together a jmpbuf
test that tries to break this. I've been told that anything
using libst is prone to breakage on PA without some ugly
hacks (e.g. lurker).

The second .dpatch fixes our mcontext_t problem. I don't 
know what was going on with out rather wonky definition, but 
I'm probably sure it was just bitrot. I've specified that
a signal context _is_ just a machine context. Kernel and 
glibc are now in sync.

This brings up another issue! When passing the sigcontext
back from a 64-bit kernel, the kernel passes back 64-bit
values and the mcontext is rather useless to the signal
handler. This has _always_ been broken and has never worked
properly. I'm working on adding some rather ugly "#ifdef __LP64__"
code to arch/parisc/signal.c to have it translate the values
into a sigcontext32 that I have defined in sys32.h.
There are a few other examples in signal.c that already do
some rather ugly conversion :)

Suggested solutions:
- Widen sigcontext
- Add conversion code to signal handling path

I would rather do the later... since it doesn't change 
the way we do business across the board.

Ideas and input welcome and appreciated!

c.


[-- Attachment #2: glibc22-hppa-jmpbuf.dpatch --]
[-- Type: text/plain, Size: 872 bytes --]

#! /bin/sh -e

# DP: PA-RISC jmpbuf changes.

if [ $# -ne 2 ]; then
    echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
    exit 1
fi
case "$1" in
    -patch) patch -d "$2" -f --no-backup-if-mismatch -p1 < $0;;
    -unpatch) patch -d "$2" -f --no-backup-if-mismatch -R -p1 < $0;;
    *)
        echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
        exit 1
esac
exit 0

diff -urN glibc-2.2.5/sysdeps/hppa/bits/setjmp.h glibc-2.2.5/sysdeps/hppa/bits/setjmp.h
--- glibc-2.2.5/sysdeps/hppa/bits/setjmp.h	2002-08-08 14:03:52.000000000 -0400
+++ glibc-2.2.5/sysdeps/hppa/bits/setjmp.h	2002-08-08 14:06:04.000000000 -0400
@@ -32,7 +32,7 @@
 #endif
 
 #ifndef	_ASM
-typedef double __jmp_buf[21];
+typedef int __jmp_buf[21] __attribute__ ((aligned (8)));
 #endif
 
 /* Test if longjmp to JMPBUF would unwind the frame containing a local

[-- Attachment #3: glibc22-hppa-mcontext.dpatch --]
[-- Type: text/plain, Size: 952 bytes --]

#! /bin/sh -e

# DP: Makes mcontext_t a typedef to sigcontext on hppa.

if [ $# -ne 2 ]; then
    echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
    exit 1
fi
case "$1" in
    -patch) patch -d "$2" -f --no-backup-if-mismatch -p1 < $0;;
    -unpatch) patch -d "$2" -f --no-backup-if-mismatch -R -p1 < $0;;
    *)
	echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
	exit 1
esac
exit 0

# append the patch here and adjust the -p? flag in the patch calls.
--- glibc-2.2.5/sysdeps/unix/sysv/linux/hppa/sys/ucontext.h	2002-08-20 20:50:17.000000000 -0400
+++ glibc-2.2.5/sysdeps/unix/sysv/linux/hppa/sys/ucontext.h	2002-08-20 20:49:01.000000000 -0400
@@ -52,11 +52,7 @@
   } fpregset_t;
 
 /* Context to describe whole processor state.  */
-typedef struct
-  {
-    gregset_t gregs;
-    fpregset_t fpregs;
-  } mcontext_t;
+typedef struct sigcontext mcontext_t;
 
 /* Userlevel context.  */
 typedef struct ucontext


             reply	other threads:[~2002-08-23 13:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-23 13:16 Carlos O'Donell [this message]
2002-08-23 15:36 ` [parisc-linux] RFC - glibc - patch reivew - 64->32 Randolph Chung
2002-08-23 16:14   ` Carlos O'Donell

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=20020823131634.GA3229@systemhalted \
    --to=carlos@baldric.uwo.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.