GitLab

Conflicts:

	compiler/main/DynFlags.hs
	compiler/main/HscMain.lhs

I naively assumed that mingw would not have unistd.h or sys/types
but it has both, yet does not have getuid() and friends.

* Frontend support (not yet used in the vectoriser)

Without any <file> arg, these flags just dump info to stderr so
are at most a mild information disclosure danger. We disallow
a <file> arg in the default -rtsopts=some mode since that will
overwrite the given file.

Ticket #3910 originally pointed out that the RTS options are a potential
security problem. For example the -t -s or -S flags can be used to
overwrite files. This would be bad in the context of CGI scripts or
setuid binaries. So we introduced a system where +RTS processing is more
or less disabled unless you pass the -rtsopts flag at link time.

This scheme is safe enough but it also really annoies users. They have
to use -rtsopts in many circumstances: with -threaded to use -N, with
-eventlog to use -l, with -prof to use any of the profiling flags. Many
users just set -rtsopts globally or in project .cabal files. Apart from
annoying users it reduces security because it means that deployed
binaries will have all RTS options enabled rather than just profiling
ones.

This patch relaxes the set of RTS options that are available in the
default -rtsopts=some case. For "deployment" ways like vanilla and
-threaded we remain quite conservative. Only --info -? --help are
allowed for vanilla. For -threaded, -N and -N<x> are allowed with a
check that x <= num cpus.

For "developer" ways like -debug, -eventlog, -prof, we allow all the
options that are special to that way. Some of these allow writing files,
but the file written is not directly under the control of the attacker.
For the setuid case (where the attacker would have control over binary
name, current dir, local symlinks etc) we check if the process is
running setuid/setgid and refuse all RTS option processing. Users would
need to use -rtsopts=all in this case.

We are making the assumption that developers will not deploy binaries
built in the -debug, -eventlog, -prof ways. And even if they do, the
damage should be limited to DOS, information disclosure and writing
files like <progname>.eventlog, not arbitrary files.

Otherwise we can use +RTS -N-1 and get 2^32 or 2^64 capabilities
which doesn't work out so well...

Enables people to turn them on/off. Defaults to on.

There were two bugs with the implementation of rebindable syntax, so I
adapted the code for if-expressions.  Also noted that rebinding of if
is a bit more restricted in the arrows case.

This reverts commit bb0eb57e.

This reverts commit 4e2121f4.

Eventlog timestamps are elapsed times (in nanoseconds) relative to the
process start. To be able to merge eventlogs from multiple processes we
need to be able to align their timelines. If they share a clock domain
(or a user judges that their clocks are sufficiently closely
synchronised) then it is sufficient to know how the eventlog timestamps
match up with the clock.

The EVENT_WALL_CLOCK_TIME contains the clock time with (up to)
nanosecond precision. It is otherwise an ordinary event and so contains
the usual timestamp for the same moment in time. It therefore enables
us to match up all the eventlog timestamps with clock time.

The other existing time utilities give us time elapsed since process
or thread start. This is for wall clock time, using the common Unix
epoch interpretation.

I don't know why it wasn't already enabled, but it seems to work.

They used to be only derived when DEBUG was on