Closed Bug 195219 Opened 22 years ago Closed 19 years ago

Implement atomic routines in IA-64 assembly language for HP-UX/ia64

Categories

(NSPR :: NSPR, defect)

4.2.1
HP
HP-UX
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wtc, Assigned: wtc)

Details

(Keywords: fixed1.8.1)

Attachments

(1 file, 4 obsolete files)

We should implement the PR_Atomic routines in IA-64 assembly code
for HP-UX/ia64.  We can use the assembly code for Linux/ia64 in
mozilla/nsprpub/pr/src/md/unix/os_Linux_ia64.s.
Attached patch Proposed patch (obsolete) — Splinter Review
I copied os_Linux_ia64.s to os_HPUX_ia64.s and removed
the non-executable stack directive at the end of the file:

  // Magic indicating no need for an executable stack
  .section .note.GNU-stack, "", @progbits ; .previous

I can build it on HP-UX IA64, both 32-bit and 64-bit builds,
and it seems to work.  I'd like to have someone at HP to
review the new os_HPUX_ia64.s file, and tell me whether it is
okay to assemble it using the C compiler like this (simplified
command line):

cc -Ae -o os_HPUX_ia64.o +DD32 +Olit=all -g +Z -UMACRO1 -DMACRO2 -I/foo/bar -c os_HPUX_ia64.s

(In 64-bit build we would use +DD64 instead of +DD32.)

The exact command line is this:

cc -Ae -o os_HPUX_ia64.o      +DD32 +Olit=all -g +Z  -UNDEBUG -DDEBUG_svrbld  -DDEBUG=1 -DXP_UNIX=1 -DHPUX=1 -D_HPUX_SOURCE=1 -D_PR_POLL_WITH_SELECT=1 -D_USE_BIG_FDS=1 -DHAVE_POINTER_LOCALTIME_R=1 -DHPUX10=1 -DHPUX11=1 -D_LARGEFILE64_SOURCE=1 -D_PR_HAVE_OFF64_T=1 -DHAVE_FCNTL_FILE_LOCKING=1 -DHAVE_LCHOWN=1 -DHAVE_STRERROR=1 -D_POSIX_C_SOURCE=199506L -D_PR_HAVE_THREADSAFE_GETHOST=1  -DFORCE_PR_LOG -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM -D_PR_INET6 -D_NSPR_BUILD_ -I../../../../dist/include/nspr -I../../../../../mozilla/nsprpub/pr/include -I../../../../../mozilla/nsprpub/pr/include/private  -c ../../../../../mozilla/nsprpub/pr/src/md/unix/os_HPUX_ia64.s
I found that the previous patch has a typo (__ia64__
should be __ia64), which prevented it from using the
assembly code.  I fixed that in this patch, but found
that only the 64-bit build works.  The 32-bit build crashed
with this stack trace:

twister[svrbld]:/share/dev1/wtchang/nspr-tip/hpux32.dbg/pr/tests> gdb cvar
HP gdb 5.0 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.0 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
(gdb) run
Starting program: /share/dev1/wtchang/nspr-tip/hpux32.dbg/pr/tests/cvar

Program received signal SIGSEGV, Segmentation fault
  si_code: 1 - SEGV_MAPERR - Address not mapped to object.
[Switching to process 3571]
0x200000007ef6f5c0:0 in _PR_ia64_AtomicIncrement+0 ()
   from /share/dev1/wtchang/nspr-tip/hpux32.dbg/pr/tests/../../dist/lib/libnspr4.so
(gdb) where
#0  0x200000007ef6f5c0:0 in _PR_ia64_AtomicIncrement+0 ()
   from /share/dev1/wtchang/nspr-tip/hpux32.dbg/pr/tests/../../dist/lib/libnspr4.so
#1  0x200000007ef10f00:0 in PR_AtomicIncrement (val=0x4000291c)
    at ../../../../mozilla/nsprpub/pr/src/misc/pratom.c:304
#2  0x200000007ef42660:0 in pt_PostNotifyToCvar (cvar=0x400028e0, broadcast=1)
    at ../../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:329
#3  0x200000007ef43570:0 in PR_NotifyAllCondVar (cvar=0x400028e0)
    at ../../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:440
#4  0x200000007ef5e7e0:0 in _PR_CreateThread (type=PR_USER_THREAD,
    start=0x40012a0 <.opd>, arg=0x40006900, priority=PR_PRIORITY_NORMAL,
    scope=PR_GLOBAL_THREAD, state=PR_UNJOINABLE_THREAD, stackSize=0,
    isGCAble=0) at ../../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:521
#5  0x200000007ef5e9e0:0 in PR_CreateThread (type=PR_USER_THREAD,
    start=0x40012a0 <.opd>, arg=0x40006900, priority=PR_PRIORITY_NORMAL,
    scope=PR_LOCAL_THREAD, state=PR_UNJOINABLE_THREAD, stackSize=0)
    at ../../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:538
#6  0x4001f60:0 in CondWaitContextSwitch (scope1=PR_LOCAL_THREAD,
    scope2=PR_LOCAL_THREAD) at ../../../mozilla/nsprpub/pr/tests/cvar.c:218
#7  0x4002270:0 in CondWaitContextSwitchUU ()
    at ../../../mozilla/nsprpub/pr/tests/cvar.c:245
#8  0x40023e0:0 in Measure (func=0x40012c0 <.opd+0x20>,
    msg=0x40010f0 "cond var wait context switch- user/user")
---Type <return> to continue, or q <return> to quit---
    at ../../../mozilla/nsprpub/pr/tests/cvar.c:266
#9  0x4002a40:0 in RealMain (argc=1, argv=0x7ffffc60)
    at ../../../mozilla/nsprpub/pr/tests/cvar.c:312
#10 0x200000007ef20c00:0 in PR_Initialize (prmain=0x40012f0 <.opd+0x50>,
    argc=1, argv=0x7ffffc60, maxPTDs=0)
    at ../../../../mozilla/nsprpub/pr/src/misc/prinit.c:321
#11 0x4002d20:0 in main (argc=1, argv=0x7ffffc60)
    at ../../../mozilla/nsprpub/pr/tests/cvar.c:332
(gdb)
Attachment #203200 - Attachment is obsolete: true
Attached file Preprocessed os_HPUX_ia64.s (obsolete) —
This is the C preprocessor output of the proposed os_HPUX_ia64.s file.
Attached file os_HPUX_ia64.s (obsolete) —
Attached patch Proposed patchSplinter Review
Dennis Handly of HP pointed out that 32-bit builds need
to use the addp4 instruction to convert a 32-bit address
to a 64-bit one.  That fixed the 32-bit build crash.
Attachment #203204 - Attachment is obsolete: true
Attachment #203326 - Attachment is obsolete: true
Attachment #203327 - Attachment is obsolete: true
Patch checked in on the NSPR trunk (NSPR 4.7) and the
NSPRPUB_PRE_4_2_CLIENT_BRANCH (Mozilla 1.9a).
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: [4.7]
Whiteboard: [4.7]
Target Milestone: --- → 4.7
I checked in the patch on the NSPR_4_6_BRANCH (NSPR 4.6.2).

Checking in configure;
/cvsroot/mozilla/nsprpub/configure,v  <--  configure
new revision: 1.197.2.1; previous revision: 1.197
done
Checking in configure.in;
/cvsroot/mozilla/nsprpub/configure.in,v  <--  configure.in
new revision: 1.199.2.1; previous revision: 1.199
done
Checking in pr/include/md/_hpux.h;
/cvsroot/mozilla/nsprpub/pr/include/md/_hpux.h,v  <--  _hpux.h
new revision: 3.18.2.1; previous revision: 3.18
done
Checking in pr/src/md/unix/os_HPUX_ia64.s;
/cvsroot/mozilla/nsprpub/pr/src/md/unix/os_HPUX_ia64.s,v  <--  os_HPUX_ia64.s
new revision: 1.2.2.2; previous revision: 1.2.2.1
done
Target Milestone: 4.7 → 4.6.2
Comment on attachment 203845 [details] [diff] [review]
Proposed patch

These changes only affect HP-UX ia64.  The reason
I want to check them in on the MOZILLA_1_8_BRANCH
and MOZILLA_1_8_0_BRANCH is to keep those Mozilla
NSPR branches in sync with the official NSPR_4_6_BRANCH.
Attachment #203845 - Flags: approval1.8.1?
Attachment #203845 - Flags: approval1.8.0.1?
> These changes only affect HP-UX ia64.

If that's true why did a previous version cause the 32-bit build to crash? Having to use "#ifndef _LP64" to protect 32-bit builds from a file called os_HPUX_ia64.s makes me wonder if either your makefile or the filename must be wrong.
The 32-bit build that crashed is the 32-bit HP-UX ia64 build.
HP-UX ia64 supports both 32-bit and 64-bit ELF objects.
Comment on attachment 203845 [details] [diff] [review]
Proposed patch

When the tree reopens for 1.8.0.2 we'll let this in.
Attachment #203845 - Flags: approval1.8.1?
Attachment #203845 - Flags: approval1.8.1+
Attachment #203845 - Flags: approval1.8.0.2?
Attachment #203845 - Flags: approval1.8.0.1?
Attachment #203845 - Flags: approval1.8.0.1-
I checked in the patch on the MOZILLA_1_8_BRANCH.

Checking in configure;
/cvsroot/mozilla/nsprpub/configure,v  <--  configure
new revision: 1.78.2.108.4.8; previous revision: 1.78.2.108.4.7
done
Checking in configure.in;
/cvsroot/mozilla/nsprpub/configure.in,v  <--  configure.in
new revision: 1.83.2.106.4.8; previous revision: 1.83.2.106.4.7
done
Checking in pr/include/md/_hpux.h;
/cvsroot/mozilla/nsprpub/pr/include/md/_hpux.h,v  <--  _hpux.h
new revision: 3.11.4.5.32.1; previous revision: 3.11.4.5
done
Checking in pr/src/md/unix/os_HPUX_ia64.s;
/cvsroot/mozilla/nsprpub/pr/src/md/unix/os_HPUX_ia64.s,v  <--  os_HPUX_ia64.s
new revision: 1.2.4.2; previous revision: 1.2.4.1
done
Keywords: fixed1.8.1
Flags: blocking1.8.0.2+
Comment on attachment 203845 [details] [diff] [review]
Proposed patch

approved for 1.8.0 branch, a=dveditz
Attachment #203845 - Flags: approval1.8.0.2? → approval1.8.0.2+
I withdrew my blocking1.8.0.2 request.
Flags: blocking1.8.0.2+
Comment on attachment 203845 [details] [diff] [review]
Proposed patch

minus for 1.8.0.2 per wtc
Attachment #203845 - Flags: approval1.8.0.2+ → approval1.8.0.2-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: