Create .map files for security DLLs

VERIFIED FIXED in 3.10.2

Status

NSS
Build
VERIFIED FIXED
13 years ago
13 years ago

People

(Reporter: Peter Weilbacher, Assigned: Peter Weilbacher)

Tracking

unspecified
3.10.2
x86
OS/2

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

966 bytes, patch
Julien Pierre
: review+
mkaply
: superreview+
chris hofmann
: approval1.8b3+
Details | Diff | Splinter Review
(Assignee)

Description

13 years ago
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

13 years ago
Hups, didn't want to CC you but Julien Pierre...
(Assignee)

Comment 2

13 years ago
Created attachment 186389 [details] [diff] [review]
add -Zmap

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

13 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

13 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

13 years ago
Mike, could you look at this patch?

Comment 6

13 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

13 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

13 years ago
Comment on attachment 186389 [details] [diff] [review]
add -Zmap

sr=mkaply
Attachment #186389 - Flags: superreview?(mozilla) → superreview+

Comment 9

13 years ago
Peter: I didn't know that Mozilla uses $(LDFLAGS) when building
a DLL/shared library.  Thanks for correcting me.

Comment 10

13 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

13 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

13 years ago
Attachment #186389 - Flags: review?(julien.pierre.bugs) → review+
(Assignee)

Comment 12

13 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

13 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
Last Resolved: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.10.1

Comment 14

13 years ago
Comment on attachment 186389 [details] [diff] [review]
add -Zmap

a=chofmann
Attachment #186389 - Flags: approval1.8b3? → approval1.8b3+
(Assignee)

Comment 15

13 years ago
Julien or Mike, could you also check this into the normal Mozilla trunk?

Updated

13 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.