in Emacs GDB mode.
TODO:
* Pipe command output in the child through the debugger rather
than sending it straight to stdout.
* Redirect stdin/stdout/stderr as needed and format the output.
* Add a proper switch between console and mi.
* Finish implementing the stub functions.
* Get Emacs commands for viewing data and the stack working.
* Commands are no longer capped at 8 tokens
* Mark functions as static
* Add declaration of debugger( void ) in debugger.h
* Use f ( void ) instead of f ( )
The interface is a subset of gdb.
TODO:
* Put this behind flag, so it's possible to run b2 without the debugger.
Perhaps -db?
* Keep a command history and allow it to be accessed.
* Abbreviate long arguments in the backtrace, and wrap
long lines better.
* Implement more commands. I'm thinking of watch, condition, and ignore in
particular.
* Test the runtime cost. If it doesn't have any noticable penalty
when it's off, then it's safe to integrate this functionality
into the primary b2 executable.
* Write documentation.
* IDE integration. I'm hoping that I can hijack gdb support for any
editor that has built in support for gdb.
The mentioned 'standard' path were quite old (9.0, last Intel
compiler version is 15.x as on Oct 2014). Keept the legacy
detection though.
Build in 64 bit (seems more common).
A user is having trouble with calls to setpgid failing
with EPERM and we're not sure whether it's the call to
the parent, or child process that is the source of the
failure. Add check with explicit indication whether
the parent of child failed.
Technique used for setting Windows batch script exit codes in Boost.Build worked
correctly when the script is called from a Windows shell process and then checked
from inside that process. However, when run from a temporary shell process that
needs to terminate after running the script, such a process would always return
exit code 0.
This prevented anyone automating those scripts from detecting their success/
failure status by using their exit code without adding an additional batch script
layer.
For example, consider the following two script files:
ret666.cmd:
exit /b 666
wrapper.cmd:
call ret666.cmd
They both 'should return the value 666' and when run directly from a cmd.exe
console indeed both do (they set the shell process's ERRORLEVEL environment
variable to 666). However, when run like this:
cmd /c <script-name>
running ret666.cmd causes the temporary cmd.exe process to exit with exit code
666, while running wrapper.cmd causes it to exit with exit code 0.
Select was losing child termination signals so we explictly
block SIGCHLD during select, and unblock after select returns.
Tested on 256 core smp system, no hangs or zombies. Thanks
to Alain Miniussi <alain.miniussi@oca.eu> for reporting this.
This change allows top-level scripts to determine which
toolchain was used by Boost.Build engine bootstrap process.
Top-level script of Boost C++ Libraries will be updated
separately.
If we have to wait for, e.g. 65 jobs, first we create a thread which waits for first 63.
The remaining two can be waited on by the same WFMO call which waits for thread
completion. This will avoid creating 2 threads in this case.
Windows WaitForMultipleObjects() can wait on max. 64 handles. This limitation is overcome by splitting the handle set into parts which are of adequate size, and spawning a thread which does the waiting.
