mirror of
https://github.com/Mercury-Language/mercury.git
synced 2026-04-15 09:23:44 +00:00
cb28daa00a
Fix some problems that were preventing the system from compiling properly with MSVC. (1) Visual Studio 2013 no longer includes the files NtWin32.Mak and Win32.Mak which are required for building the Boehm GC with MSVC. (This appears to be an issue with upstream Boehm as well.) The workaround here is to reference the copies of this files included with the Windows 7 SDK. (This appears to be the official Microsoft workaround for dealing with this problem for now.) (2) Disable support for `--c-debug' when using MSVC. Using this option causes MSVC to emit .pdb (Program Data Base), that contain the symbol information for an object files. This causes a variety of problems: (i) parallel builds are contending for the vc*.pdb file shared by all the object files in a directory causing compilation to abort. (Compiling with the -FS option is another solution to this -- it causes the compiler to serialize access to the .pdb file -- but at the cost of slowing down compilation.) (ii) .pdb files are not cleaned up by realclean; compilation will abort if a pdb file generated by a different version of MSVC is encountered. (iii) we don't install the .pdb files alongside the libraries anyway. This can be a source of linker warnings. (And shutting up the Microsoft linker seems to be very difficult indeed ...) (iv) compiling with -Zi (apparently) inhibits some C compiler optimizations. Compiling with the older -Z7 (MSVC 7 style debugging info) option is another alternative. Using that option causes MSVC to include symbol information in the object files, instead of in a separate file. For now (i.e. the 14.01 release), disabling `--c-debug' for MSVC is the simplest way of addressing the above issues. README.MS-VisualC: Describe the problem with NtWin32.Mak and Visual Studio 2013 and provide two possible workarounds. Mention that `--c-debug' is not currently supported with MSVC and how to re-enable it. Simplify some of the instructions for setting up the build environment. configure.ac: scripts/mgnuc.in: Disable `--c-debug' with MSVC. scripts/prepare_install_dir.in: Copy all makefile fragments for nmake into the boehm_gc directory for the library grade installation. (This is in case the user copies NtWin32.Mak etc into the boehm_gc directory as per the second of the workarounds in README.MS-VisualC.) slice/Mmakefile: compiler/Mmakefile: deep_profiler/Mmakefile: mfilterjavac/Mmakefile: profiler/Mmakefile: slice/Mmakefile: Clean up any .pdb files. Note that one is generated for each executable (regardless of whether -Zi is given to cl or not). In addition, if -Zi is given to cl, there will be file named vc<version>.pdb generated (where <version> is the version of MSVC being used.)
Threadscope
===========
This file contains information about threadscope profiling for Mercury.
1. Supported Systems.
2. Threadscope Profiling Tools
NOTICE
------
ThreadScope support is currently broken and therefore unsupported. We have
plans to fix it for a future release.
Supported Systems
-----------------
Threadscope uses the RDTSCP or RDTSC instructions found on some x86 and x86_64
processors to get fast, high precision timing information. These instructions
read the time stamp counter (TSC), this is incremented for every clock cycle.
Processors must increment this at a constant rate, regardless of their power
state, (see /proc/cpuinfo for constant_tsc).
TSC must also be synchronised between processors in the same system, although
it may be possible to work around this, let me know if you have such a system
(See contact info).
AMD processors do not seem to store their clock frequency in their brand ID
string. On these systems Theadscope profiles are not to scale since clock
counts cannot be converted into time in nanoseconds. The threadscope profile
will count one nanosecond for each clock tick.
I have had success with the following processors:
Intel Core2
Intel Xeon CPU X5472 (in a dual socket system).
Processors that do not work correctly:
AMD Athlon 64 X2
Threadscope Profiling Tools
---------------------------
Mercury supports threadscope profiling. See the profiling section in the user
guide.
The Threadscope profiling tools are written in Haskell and are known to work
with GHC 6.10. threadscope depends upon the following Haskell libraries:
array
binary
containers
filepath
ghc-events
gtk2hs
mtl
Many of these will be provided with GHC or packaged for/by your operating
system.
ghc-events is not packaged by most operating systems at this stage, It can be
retrieved from hackage:
http://hackage.haskell.org/package/ghc-events
threadscope itself can also be retrieved from hackage:
http://hackage.haskell.org/package/threadscope
Information about how to install Haskell packages can be found here:
http://haskell.org/haskellwiki/Cabal/How_to_install_a_Cabal_package