Closed Bug 195219 Opened 22 years ago Closed 20 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: 20 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: