User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20070531 CentOS/22.214.171.124-1.el5.centos Firefox/126.96.36.199 Build Identifier: The ARM EABI is a newer ABI which fixes some of the warts in the old ABI. On EABI, glibc uses a different jmp_buf size and layout, which breaks nspr's assumptions about the structure of jmp_buf on ARM systems. The attached patch (against nspr 4.6.6) fixes these assumptions, and results in a successful subsequent nss build. Please consider applying this patch. Thanks for your time. Reproducible: Always
Over to Brad Lassey for some ARM love.
Assignee: wtc → blassey
Lennert, can you attach a test case to show where this bug manifests itself? and what the expected behavior would be?
If I build nspr without this patch, and then build nss, I end up with a version of shlibsign that segfaults when I actually try to sign something. It's about half a year ago that I originally debugged this, and the link between the backtrace and the jmp_buf structure changes isn't immediately obvious. I can't remember anymore how I tracked this down to the jmp_buf EABI changes at the time off the top of my head, all I know at this point is that running shlibsign consistently crashes without the patch, and works fine with the patch. :-( I'll gladly supply developers with shell accounts on Fedora/ARM machines so that they can test this out for themselves. FWIW, here is the backtrace: [root@iop pr]# gdb /usr/lib/nss/unsupported-tools/shlibsign GNU gdb Red Hat Linux (6.6-15.fc8.fa1rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "armv5tel-redhat-linux-gnueabi"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -i /usr/lib/libsoftokn3.so Starting program: /usr/lib/nss/unsupported-tools/shlibsign -i /usr/lib/libsoftokn3.so [Thread debugging using libthread_db enabled] [New process 18533] [New Thread 358043120 (LWP 18533)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 358043120 (LWP 18533)] mult (a=0x4e340, b=0x4e340) at ../../../mozilla/nsprpub/pr/src/misc/prdtoa.c:860 860 *x = 0; (gdb) bt #0 mult (a=0x4e340, b=0x4e340) at ../../../mozilla/nsprpub/pr/src/misc/prdtoa.c:860 #1 0x1567346c in pow5mult (b=0x158a9008, k=<value optimized out>) at ../../../mozilla/nsprpub/pr/src/misc/prdtoa.c:981 #2 0x156747ec in PR_dtoa (d=<value optimized out>, mode=1, ndigits=1, decpt=0x3ee5c470, sign=0x0, rve=0x3ee5c468, buf=0x3ee5c474 "\020", bufsize=64) at ../../../mozilla/nsprpub/pr/src/misc/prdtoa.c:3151 #3 0x15634444 in set_whatnspr () at whatnspr.c:76 #4 0x15634634 in nss_NewThreadPrivateIndex (ip=0x15649830, dtor=0x15670bac <PR_Free>) at whatnspr.c:106 #5 0x15676ff0 in PR_CallOnce (once=0x15649834, func=0x15632f50 <error_once_function>) at ../../../mozilla/nsprpub/pr/src/misc/prinit.c:811 #6 0x15632e90 in error_get_my_stack () at error.c:121 #7 0x15632eb8 in nss_ClearErrorStack () at error.c:278 #8 0x15632dc8 in NSSArena_Create () at arena.c:385 #9 0x15628d84 in NSSTrustDomain_Create (moduleOpt=0x156be53c "\003", uriOpt=0x156992cc "", opaqueOpt=0x0, reserved=0x1569a000) at trustdomain.c:90 #10 0x1562d3dc in STAN_LoadDefaultNSS3TrustDomain () at pki3hack.c:140 #11 0x155e5bac in nss_Init (configdir=0x15634bd4 "", certPrefix=<value optimized out>, keyPrefix=<value optimized out>, secmodName=0x15634bd4 "", readOnly=0, noCertDB=0, noModDB=3, forceOpen=358912776, noRootInit=1, optimizeSpace=142456, noSingleThreadedModules=0, allowAlreadyInitializedModules=0, dontFinalizeModules=0) at nssinit.c:493 #12 0x155e5e78 in NSS_NoDB_Init (configdir=<value optimized out>) at nssinit.c:601 #13 0x0000b220 in main (argc=<value optimized out>, argv=<value optimized out>) at shlibsign.c:224 #14 0x156d7db8 in __libc_start_main (main=0, argc=0, ubp_av=0x0, init=<value optimized out>, fini=0x136e0 <__libc_csu_fini>, rtld_fini=0, stack_end=0x3ee5da64) at libc-start.c:220 #15 0x0000ad3c in _start () (gdb) print x $1 = (PRUint32 *) 0x1569a000 From /proc/$foo/maps, x is pointing to the first page of libpthread.so: 1569a000-156ad000 r-xp 00000000 08:01 26201388 /lib/libpthread-2.7.so
Comment on attachment 269516 [details] [diff] [review] Patch against nspr 4.6.6 which fixes jmp_buf assumptions on ARM EABI. +#elif defined(__arm__) && !defined(__ARM_EABI__) /* ARM/Linux */ +#elif defined(__arm__) && defined(__ARM_EABI__) +/* ARM/Linux */ this is confusing. the first comment clearly means "ARM, not ARMEL" the second comment otoh means "ARM and ARMEL".
"armel" is only the name that Debian uses for "Linux/ARM EABI". But I agree that the comments could be clearer. How about: +#elif defined(__arm__) && !defined(__ARM_EABI__) +/* ARM/Linux old-ABI */ +#elif defined(__arm__) && defined(__ARM_EABI__) +/* ARM/Linux EABI */
FWIW, these are the relevant glibc bits: On old-ABI, ports/sysdeps/arm/fpu/setjmp.S first stores f4/f5/f6/f7 in jmp_buf (12 bytes each), and then stores v1-v6, sl, fp, sp and lr, which is consistent with the current nsprpub/pr/include/md/_linux.h using word 19 for fp and word 20 for sp: http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/ports/sysdeps/arm/fpu/setjmp.S?rev=1.4&content-type=text/plain&cvsroot=glibc On EABI, the integer registers are stored first, and the floating point stuff lives at the end, making fp word 7 and sp word 8: http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/ports/sysdeps/arm/eabi/setjmp.S?rev=1.2&content-type=text/plain&cvsroot=glibc
New version of the patch, incorporating feedback from "timeless" (Comment #5.)
Attachment #269516 - Attachment is obsolete: true
did this land?
no, this hasn't landed. Still needs review
What's the resolution to comment 4 ?
Lennert, thanks a lot for the patch. Sorry about the delay in reviewing your patch. I rearranged the ifdefs in your patch. I'd appreciate if you could test this patch. The fact that you needed this patch means you are NOT building NSPR with pthreads, because those five macros are only used by NSPR's user-level threads. Is that true? Why don't you configure NSPR with pthreads (which is the default)? I have checked in this patch on the NSPR trunk for NSPR 4.7.4. Checking in pr/include/md/_linux.h; /cvsroot/mozilla/nsprpub/pr/include/md/_linux.h,v <-- _linux.h new revision: 3.53; previous revision: 3.52 done
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Comment on attachment 347009 [details] [diff] [review] Patch against nspr 4.7.3 which fixes jmp_buf assumptions on ARM EABI. (checked in) I can't really test this as I don't have access to the relevant setup and software versions anymore, but the patch looks okay to me.
You need to log in before you can comment on or make changes to this bug.