Open
Bug 202293
Opened 23 years ago
Updated 3 years ago
The Win32 gcc port of NSS should use x86 assembly code
Categories
(NSS :: Libraries, defect, P3)
Tracking
(Not tracked)
NEW
People
(Reporter: wtc, Unassigned)
References
Details
The Win32 gcc port of NSS should use x86 assembly code
in the "freebl" library. We currently have:
- mpi_x86.asm: for Win32 with MSVC and OS/2 with VACPP;
- mpi_x86.s: for Linux x86;
- mpi_i86pc.s: for Solaris x86.
None of these work as is. Here is what cls said about
his attempt to use mpi_x86.s:
It turns out that GNU ld doesn't have support for stosd.
It expects to use stosl but calling stosl on win32 causs
a segfault.
Is OS/2 hitting this problem with their transition to gcc3? Or does OS/2 gcc not
use GNU binutils?
FYI, I also needed this rule to translate mpi_x86.s since win32 requires leading
underscores on symbols.
+#mpi_x86_win32.s: mpi_x86.s
+# cat $< | sed -e 's|^\.type|#.type|' -e 's|s_mpv_|_s_mpv_|g' > $@
Comment 2•23 years ago
|
||
OS/2 with gcc does use GNU binutils . From what I can tell, the OS/2 gcc build
of NSS is currently using the C implementation of mpi rather than the x86
assembly code (.s versoin). I haven't tried using the mpi_x86.s with it yet.
Changing description to reflect both Win32 & OS/2.
OS: Windows XP → other
Summary: The Win32 gcc port of NSS should use x86 assembly code → The Win32 & OS/2 gcc ports of NSS should use x86 assembly code
| Reporter | ||
Comment 3•23 years ago
|
||
*** Bug 204308 has been marked as a duplicate of this bug. ***
| Reporter | ||
Comment 4•23 years ago
|
||
Please open a separate bug for the OS/2 gcc port.
OS: other → Windows XP
Summary: The Win32 & OS/2 gcc ports of NSS should use x86 assembly code → The Win32 gcc port of NSS should use x86 assembly code
| Reporter | ||
Updated•22 years ago
|
Priority: -- → P3
Updated•20 years ago
|
QA Contact: bishakhabanerjee → jason.m.reid
Updated•20 years ago
|
QA Contact: jason.m.reid → libraries
Comment 5•4 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.
Assignee: wtc → nobody
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•