headers
Aurelien Jarno | 1 May 21:28

[PATCH] [HPPA] fix bits/pthreadtypes.h

Hi all,

On hppa using linuxthreads + TLS, bits/pthreadtypes.h is out of date 
compare to the generic linuxthreads file. This makes pthread.h unusable.

Please find below a patch to fix that.

Bye,
Aurelien

--- libc/ports/sysdeps/unix/sysv/linux/hppa/linuxthreads/bits/pthreadtypes.h	2007-05-01
21:15:38.000000000 +020
+++ libc/ports/sysdeps/unix/sysv/linux/hppa/linuxthreads/bits/pthreadtypes.h	2007-05-01
21:16:03.000000000 +0200
@@ -134,7 +134,7 @@
 } pthread_rwlockattr_t;
 #endif

-#ifdef __USE_XOPEN2K
+#if defined __USE_UNIX98 || defined __USE_XOPEN2K
 /* POSIX spinlock data type.  */
 typedef __atomic_lock_t pthread_spinlock_t;

--

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32 <at> debian.org         | aurelien <at> aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net
Permalink | Reply | 2 comments |
headers
Aurelien Jarno | 1 May 21:42

unaligned access using bash on glibc 2.5

Hi all,

We have just switched to a glibc 2.5 using LT + TLS in Debian. This
causes unaligned memory access when using bash:

bash(19279): unaligned access to 0x000e1bb2 at ip=0x407cb76b

Using prctl to trap on aligned access and gdb, the unaligned access
seems to be in closedir() (a glibc function), at the point marked by
a '*'.

   0x40bcb718 <closedir+0>:        stw rp,-14(sp)
   0x40bcb71c <closedir+4>:        stw,ma r5,40(sp)
   0x40bcb720 <closedir+8>:        stw r4,-3c(sp)
   0x40bcb724 <closedir+12>:       stw r3,-38(sp)
   0x40bcb728 <closedir+16>:       movb,= r26,r3,0x40bcb7a8 <closedir+144>
   0x40bcb72c <closedir+20>:       stw r19,-20(sp)
   0x40bcb730 <closedir+24>:       addil L%1000,r19,r1
   0x40bcb734 <closedir+28>:       ldw 0(r3),r5
   0x40bcb738 <closedir+32>:       ldw 5b0(r1),ret0
   0x40bcb73c <closedir+36>:       ldw 64(ret0),r20
   0x40bcb740 <closedir+40>:       cmpib,<> 0,r20,0x40bcb7c8 <closedir+176>
   0x40bcb744 <closedir+44>:       copy r20,r22
   0x40bcb748 <closedir+48>:       b,l 0x40bb4aa0,rp
   0x40bcb74c <closedir+52>:       copy r3,r26
   0x40bcb750 <closedir+56>:       copy r5,r26
   0x40bcb754 <closedir+60>:       copy r19,r4
   0x40bcb758 <closedir+64>:       be,l 100(sr2,r0),sr0,r31
   0x40bcb75c <closedir+68>:       ldi 6,r20
   0x40bcb760 <closedir+72>:       copy r4,r19
(Continue reading)

Permalink | Reply | 30 comments |
headers
Carlos O'Donell | 1 May 21:45

Re: [PATCH] [HPPA] fix bits/pthreadtypes.h

On 5/1/07, Aurelien Jarno <aurelien <at> aurel32.net> wrote:
> On hppa using linuxthreads + TLS, bits/pthreadtypes.h is out of date
> compare to the generic linuxthreads file. This makes pthread.h unusable.

Aurelien,

Thanks, I will look at this tonight. I'll add a Changelog and commit
to ports if everything looks good.

Cheers,
Carlos.
Permalink | Reply | 0 comments |
headers
Carlos O'Donell | 1 May 21:55

Re: unaligned access using bash on glibc 2.5

On 5/1/07, Aurelien Jarno <aurelien <at> aurel32.net> wrote:
> We have just switched to a glibc 2.5 using LT + TLS in Debian. This
> causes unaligned memory access when using bash:
>
> bash(19279): unaligned access to 0x000e1bb2 at ip=0x407cb76b

Why doesn't this ip match the runtime disassembly you have below?

> Using prctl to trap on aligned access and gdb, the unaligned access
> seems to be in closedir() (a glibc function), at the point marked by
> a '*'.

Is this a dump from disassemble in gdb at runtime?
What is the value of r19, r2, and r30 at the point of the unaligned access?

> The problem does not look obvious (at least to me). Any idea?

Yes, but I need answers to my three questions :-)

Cheers,
Carlos.
Permalink | Reply | 29 comments |
headers
Aurelien Jarno | 1 May 22:09

Re: unaligned access using bash on glibc 2.5

Carlos O'Donell a écrit :
> On 5/1/07, Aurelien Jarno <aurelien <at> aurel32.net> wrote:
>> We have just switched to a glibc 2.5 using LT + TLS in Debian. This
>> causes unaligned memory access when using bash:
>>
>> bash(19279): unaligned access to 0x000e1bb2 at ip=0x407cb76b
> 
> Why doesn't this ip match the runtime disassembly you have below?

Well I don't really now. The address return by the kernel is not
aligned, so that's strange. Note that this does not correspond to the
same execution. I run it once to get the entry in the kernel log, and
once with unaligned=signal to get the SIGBUS in gdb.

The address (computed using the contents of r1) matches.

>> Using prctl to trap on aligned access and gdb, the unaligned access
>> seems to be in closedir() (a glibc function), at the point marked by
>> a '*'.
> 
> Is this a dump from disassemble in gdb at runtime?

Yes, running in prctl --unaligned=signal

> What is the value of r19, r2, and r30 at the point of the unaligned access?

rp             0x40bcb753       1086109523
r19            0xe05c6  918982
sp             0xc04b4c00       3226160128
(Continue reading)

Permalink | Reply | 28 comments |
headers
Geert Uytterhoeven | 1 May 22:32

[patch 10/33] hilkbd: Kill compiler warning and fix comment dyslexia

hilkbd: Kill compiler warning and fix comment dyslexia

Signed-off-by: Geert Uytterhoeven <geert <at> linux-m68k.org>
---
 drivers/input/keyboard/hilkbd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-m68k-2.6.21.orig/drivers/input/keyboard/hilkbd.c
+++ linux-m68k-2.6.21/drivers/input/keyboard/hilkbd.c
@@ -52,7 +52,7 @@ MODULE_LICENSE("GPL v2");

 #elif defined(CONFIG_HP300)

- #define HILBASE		0xf0428000 /* HP300 (m86k) port address */
+ #define HILBASE		0xf0428000UL /* HP300 (m68k) port address */
  #define HIL_DATA		0x1
  #define HIL_CMD		0x3
  #define HIL_IRQ		2

--
Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert <at> linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds
(Continue reading)

Permalink | Reply | 0 comments |
headers
John David Anglin | 1 May 22:59
Picon

Re: unaligned access using bash on glibc 2.5

> Carlos O'Donell a écrit :
> > On 5/1/07, Aurelien Jarno <aurelien <at> aurel32.net> wrote:
> >> We have just switched to a glibc 2.5 using LT + TLS in Debian. This
> >> causes unaligned memory access when using bash:
> >>
> >> bash(19279): unaligned access to 0x000e1bb2 at ip=0x407cb76b
> > 
> > Why doesn't this ip match the runtime disassembly you have below?
> 
> Well I don't really now. The address return by the kernel is not
> aligned, so that's strange. Note that this does not correspond to the
> same execution. I run it once to get the entry in the kernel log, and
> once with unaligned=signal to get the SIGBUS in gdb.

The two least significant bits in ip contain the priviledge level
of the executing code.  They have to be masked off to get the address
of a faulting instruction.

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
Permalink | Reply | 27 comments |
headers
Carlos O'Donell | 2 May 03:47

Re: unaligned access using bash on glibc 2.5

On 5/1/07, John David Anglin <dave <at> hiauly1.hia.nrc.ca> wrote:
> The two least significant bits in ip contain the priviledge level
> of the executing code.  They have to be masked off to get the address
> of a faulting instruction.

You'll be pleasantly suprised to know we tracked this down to a
missing save/restore of the PIC register on a library call.

  0x40bcb744 <closedir+44>:       copy r20,r22
  0x40bcb748 <closedir+48>:       b,l 0x40bb4aa0,rp
  0x40bcb74c <closedir+52>:       copy r3,r26

See this lonely b,l without a PIC register save/restore? That's the
problem. It's a jump to a stub, which calls free, but free tailcalls
into __internal_free, and the PIC register isn't restored by free or
by closedir.

FWIW I see this aswell when compiling glibc with gcc mainline:

  10:   6b d3 3f c1     stw r19,-20(sp)
../sysdeps/unix/closedir.c:52
  14:   e8 40 00 00     b,l 1c <__closedir+0x1c>,rp
                        14: R_PARISC_PCREL17F   free
  18:   0c a0 10 85     ldw 0(r5),r5
../sysdeps/unix/closedir.c:54
  1c:   08 05 02 5a     copy r5,r26
  20:   08 13 02 44     copy r19,r4

Why isn't there a save/restore of the PIC register around the call to
free? Clearly r19 is being used, notice the save/restore starting on
(Continue reading)

Permalink | Reply | 26 comments |
headers
Carlos O'Donell | 2 May 04:07

Re: [PATCH] [HPPA] fix bits/pthreadtypes.h

On 5/1/07, Aurelien Jarno <aurelien <at> aurel32.net> wrote:
> --- libc/ports/sysdeps/unix/sysv/linux/hppa/linuxthreads/bits/pthreadtypes.h    2007-05-01
21:15:38.000000000 +020
> +++ libc/ports/sysdeps/unix/sysv/linux/hppa/linuxthreads/bits/pthreadtypes.h    2007-05-01
21:16:03.000000000 +0200
> @@ -134,7 +134,7 @@
>  } pthread_rwlockattr_t;
>  #endif
>
> -#ifdef __USE_XOPEN2K
> +#if defined __USE_UNIX98 || defined __USE_XOPEN2K
>  /* POSIX spinlock data type.  */
>  typedef __atomic_lock_t pthread_spinlock_t;

The generic pthreadtypes.h for linuxthreads does not define
pthread_spinlock_t, pthread_barrier_t, and pthread_barrierattr_t when
__USE_UNIX98 is defined. I don't think your patch is correct.

I have just checked in a patch to upadte pthreadtypes.h, but it's
different from your patch. Please verify this fixes the issue you were
seeing.

Cheers,
Carlos.
Permalink | Reply | 0 comments |
headers
Aurelien Jarno | 2 May 08:38

Re: unaligned access using bash on glibc 2.5

Carlos O'Donell a écrit :
> On 5/1/07, John David Anglin <dave <at> hiauly1.hia.nrc.ca> wrote:
>> The two least significant bits in ip contain the priviledge level
>> of the executing code.  They have to be masked off to get the address
>> of a faulting instruction.
> 
> You'll be pleasantly suprised to know we tracked this down to a
> missing save/restore of the PIC register on a library call.
> 
>   0x40bcb744 <closedir+44>:       copy r20,r22
>   0x40bcb748 <closedir+48>:       b,l 0x40bb4aa0,rp
>   0x40bcb74c <closedir+52>:       copy r3,r26
> 
> See this lonely b,l without a PIC register save/restore? That's the
> problem. It's a jump to a stub, which calls free, but free tailcalls
> into __internal_free, and the PIC register isn't restored by free or
> by closedir.
> 
> FWIW I see this aswell when compiling glibc with gcc mainline:
> 
>   10:   6b d3 3f c1     stw r19,-20(sp)
> ../sysdeps/unix/closedir.c:52
>   14:   e8 40 00 00     b,l 1c <__closedir+0x1c>,rp
>                         14: R_PARISC_PCREL17F   free
>   18:   0c a0 10 85     ldw 0(r5),r5
> ../sysdeps/unix/closedir.c:54
>   1c:   08 05 02 5a     copy r5,r26
>   20:   08 13 02 44     copy r19,r4
> 
> Why isn't there a save/restore of the PIC register around the call to
(Continue reading)

Permalink | Reply | 24 comments |

Gmane