Closed
Bug 297826
Opened 20 years ago
Closed 20 years ago
Create .map files for security DLLs
Categories
(NSS :: Build, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
3.10.2
People
(Reporter: mozilla, Assigned: mozilla)
Details
Attachments
(1 file)
966 bytes,
patch
|
julien.pierre
:
review+
mkaply
:
superreview+
chofmann
:
approval1.8b3+
|
Details | Diff | Splinter Review |
For some tests on profiling on OS/2 I needed .map files for all DLLs (to further
create .sym files from them). The ones from security/ are linked without -Zmap
while all others seem to be linked with that, so it would be nice to add that
parameter to the GCC setup for OS/2.
Assignee | ||
Comment 1•20 years ago
|
||
Hups, didn't want to CC you but Julien Pierre...
Assignee | ||
Comment 2•20 years ago
|
||
This seems to be the right place to add the parameter.
Assignee: wtchang → mozilla
Status: NEW → ASSIGNED
Attachment #186389 -
Flags: superreview?(wtchang)
Attachment #186389 -
Flags: review?(julien.pierre.bugs)
Comment 3•20 years ago
|
||
What is the effect of -Zmap . Does it have any effect on performance ? Do you
want too do it for both optimized and debug builds ? And should it be set only
in DSO_LDOPTS for shared libraries, or also in LDFLAGS for the NSS command-line
executables ? You can build the command-line tools by doing a gmake
nss_build_all in mozilla/security/nss .
Assignee | ||
Comment 4•20 years ago
|
||
It just produces a .map file for the corresponding .dll (or .exe) that is linked
in the directory that it is produced in. This is mainly for finding out
addresses from crash screens (POPUPLOG.OS2) but as it contains the offset of
each function within the DLL it can in principle also be used for profiling. It
does not affect the .dll itself in any way.
I don't need it for the .exe tools but it doesn't do any harm (perhaps just
takes a second more for compilation).
It is not installed into the bin/ directory so it has no effect on download size.
Comment 5•20 years ago
|
||
Mike, could you look at this patch?
Comment 6•20 years ago
|
||
Comment on attachment 186389 [details] [diff] [review]
add -Zmap
This patch is fine by me. I found that both NSPR and
the Directory C SDK use -Zmap, but Mozilla itself doesn't.
I don't know why the discrepancy.
Attachment #186389 -
Flags: superreview?(wtchang) → superreview?(mozilla)
Assignee | ||
Comment 7•20 years ago
|
||
Mozilla itself does, too. For the current GCC build environment it is added to
LDFLAGS in configure.in (currently line 1727).
Comment 8•20 years ago
|
||
Comment on attachment 186389 [details] [diff] [review]
add -Zmap
sr=mkaply
Attachment #186389 -
Flags: superreview?(mozilla) → superreview+
Comment 9•20 years ago
|
||
Peter: I didn't know that Mozilla uses $(LDFLAGS) when building
a DLL/shared library. Thanks for correcting me.
Comment 10•20 years ago
|
||
Just curious: why don't we need to set CC (the C compiler)
in mozilla/security/coreconf/OS2.mk? Is the default value
"cc" good for both GCC and Visual Age?
Comment 11•20 years ago
|
||
Wan-Teh, "cc" is good for neither compiler one OS/2, it's either gcc or icc
AFAIK. It must be getting set somewhere else.
Updated•20 years ago
|
Attachment #186389 -
Flags: review?(julien.pierre.bugs) → review+
Assignee | ||
Comment 12•20 years ago
|
||
Comment on attachment 186389 [details] [diff] [review]
add -Zmap
This is just a convenience for certain development, OS/2 only, has no effect on
code generation and shipped binaries, so it's very low risk.
Attachment #186389 -
Flags: approval1.8b3?
Comment 13•20 years ago
|
||
Patch checked in on the NSS trunk for NSS 3.10.1.
Checking in OS2.mk;
/cvsroot/mozilla/security/coreconf/OS2.mk,v <-- OS2.mk
new revision: 1.21; previous revision: 1.20
done
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.10.1
Comment 14•20 years ago
|
||
Comment on attachment 186389 [details] [diff] [review]
add -Zmap
a=chofmann
Attachment #186389 -
Flags: approval1.8b3? → approval1.8b3+
Assignee | ||
Comment 15•20 years ago
|
||
Julien or Mike, could you also check this into the normal Mozilla trunk?
Updated•19 years ago
|
Status: RESOLVED → VERIFIED
Target Milestone: 3.10.1 → 3.10.2
You need to log in
before you can comment on or make changes to this bug.
Description
•