Closed Bug 297826 Opened 20 years ago Closed 20 years ago

Create .map files for security DLLs

Categories

(NSS :: Build, defect)

x86
OS/2
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
3.10.2

People

(Reporter: mozilla, Assigned: mozilla)

Details

Attachments

(1 file)

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.
Hups, didn't want to CC you but Julien Pierre...
Attached patch add -ZmapSplinter Review
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)
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 .
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.
Mike, could you look at this patch?
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)
Mozilla itself does, too. For the current GCC build environment it is added to LDFLAGS in configure.in (currently line 1727).
Comment on attachment 186389 [details] [diff] [review] add -Zmap sr=mkaply
Attachment #186389 - Flags: superreview?(mozilla) → superreview+
Peter: I didn't know that Mozilla uses $(LDFLAGS) when building a DLL/shared library. Thanks for correcting me.
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?
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.
Attachment #186389 - Flags: review?(julien.pierre.bugs) → review+
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?
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 on attachment 186389 [details] [diff] [review] add -Zmap a=chofmann
Attachment #186389 - Flags: approval1.8b3? → approval1.8b3+
Julien or Mike, could you also check this into the normal Mozilla trunk?
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.

Attachment

General

Created:
Updated:
Size: