- 01 Nov, 2011 3 commits
-
-
dterei authored
Conflicts: compiler/main/DynFlags.hs compiler/main/HscMain.lhs
-
-
Simon Peyton Jones authored
-
- 31 Oct, 2011 10 commits
-
-
Duncan Coutts authored
-
Michal Terepeta authored
-
Michal Terepeta authored
-
Duncan Coutts authored
I naively assumed that mingw would not have unistd.h or sys/types but it has both, yet does not have getuid() and friends.
-
chak@cse.unsw.edu.au. authored
* Frontend support (not yet used in the vectoriser)
-
chak@cse.unsw.edu.au. authored
-
chak@cse.unsw.edu.au. authored
-
chak@cse.unsw.edu.au. authored
-
chak@cse.unsw.edu.au. authored
-
chak@cse.unsw.edu.au. authored
-
- 30 Oct, 2011 1 commit
-
-
batterseapower authored
-
- 27 Oct, 2011 5 commits
-
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
Otherwise we can use +RTS -N-1 and get 2^32 or 2^64 capabilities which doesn't work out so well...
-
Duncan Coutts authored
-
Duncan Coutts authored
Enables people to turn them on/off. Defaults to on.
-
- 26 Oct, 2011 12 commits
-
-
http://darcs.haskell.org/ghcIan Lynagh authored
-
Ross Paterson authored
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.
-
Ian Lynagh authored
-
Ian Lynagh authored
This reverts commit bb0eb57e.
-
Ian Lynagh authored
This reverts commit 4e2121f4.
-
Ian Lynagh authored
-
Duncan Coutts authored
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
-
Duncan Coutts authored
-
batterseapower authored
-
- 25 Oct, 2011 9 commits
-
-
dterei authored
-
dterei authored
-
dterei authored
-
dterei authored
-
http://darcs.haskell.org/ghcIan Lynagh authored
-
Ian Lynagh authored
I don't know why it wasn't already enabled, but it seems to work.
-
Simon Peyton Jones authored
-
Ian Lynagh authored
They used to be only derived when DEBUG was on
-
Ian Lynagh authored
-