and rust_exit_task_glue calls the rust main.
This is simpler since we only need to setup one frame. It also matches
what ld.so does, so gdb is happy and stops a backtrace at rust_exit_task_glue
instead of continuing past whatever function happened to be before
rust_exit_task_glue is the object file.
This is the rt part and should be merged after the rust0 part.
This applies c11675 by Julian Seward from valgrind trunk
(svn://svn.valgrind.org/valgrind/trunk) to rustrt's included
copies of memcheck.h and valgrind.h, effectively backporting
the fix from the unreleased 3.6.2. The commit simply applies
the gcc 'unused' attribute to the relevant declarations.
This change allows compilation of the runtime code under
gcc 4.6 with -Werror, as the makefile currently requests.
duplication, but we will hopefully drop the rustboot one soon.
This is also a preparation for changing the rustc one to have the activate glue
return to the exit glue which will then call the main function.
This (returning to the function that calls main) matches what happens when
loader stats a program or a new thread. It lets gdb produce good backtraces
and should help with EH too.
See https://github.com/graydon/rust/wiki/Logging-vision
The runtime logging categories are now treated in the same way as
modules in compiled code. Each domain now has a log_lvl that can be
used to restrict the logging from that domain (will be used to allow
logging to be restricted to a single domain).
Features dropped (can be brought back to life if there is interest):
- Logger indentation
- Multiple categories per log statement
- I possibly broke some of the color code -- it confuses me
Apparently it can't live in the main binary, since on non-Linux
platforms, dynamics libs won't find symbols in the binary. This
removes the crate_map pointer from rust_crate again, and instead
passes it as an extra argument to rust_start. Rustboot doesn't pass
this argument, but supposedly that's okay as long as we don't actually
use it on that platform.
This overloads the meaning of RUST_LOG to also allow
'module.submodule' or 'module.somethingelse=2' forms. The first turn
on all logging for a module (loglevel 3), the second sets its loglevel
to 2. Log levels are:
0: Show only errors
1: Errors and warnings
2: Errors, warnings, and notes
3: Everything, including debug logging
Right now, since we only have one 'log' operation, everything happens
at level 1 (warning), so the only meaningful thing that can be done
with the new RUST_LOG support is disable logging (=0) for some
modules.
TODOS:
* Language support for logging at a specific level
* Also add a log level field to tasks, query the current task as well
as the current module before logging (log if one of them allows it)
* Revise the C logging API to conform to this set-up (globals for
per-module log level, query the task level before logging, stop
using a global mask)
Implementation notes:
Crates now contain two extra data structures. A 'module map' that
contains names and pointers to the module-log-level globals for each
module in the crate that logs, and a 'crate map' that points at the
crate's module map, as well as at the crate maps of all external
crates it depends on. These are walked by the runtime (in
rust_crate.cpp) to set the currect log levels based on RUST_LOG.
These module log globals are allocated as-needed whenever a log
expression is encountered, and their location is hard-coded into the
logging code, which compares the current level to the log statement's
level, and skips over all logging code when it is lower.
floats. However, if someone writes a literal that can't be represented
precisely in 64 bits, the front-end will accept it while the back-end
will (presumably) complain.