| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
We want to get rid of the stupid -drop-ld-preload flag in qemu upstream.
Therefor mandatory for sb2 2.0. release :)
Only lightly tested but appears to work as expected.
Signed-off-by: Riku Voipio <riku.voipio@iki.fi>
|
|
- an exec policy can now define more than one rule to map the script
interpreter (previously only one rule was allowed)
- "devel" mode: Added yet another SB1 compatibility feature: Support
for mapping interpreters from /scratchbox/tools/bin to <tools_root>/usr/bin
- Interface version of the mapping engine <-> mapping rules interface
was incremented (this is the lua<->lua interface version, C<->lua interface
was not modified)
|
|
- happened because C->Lua interface left trash to Lua's stack => script
execution failed to find corect exec_policy for the script interpreter
- Also included:
- added new debugging level NOISE3
- added dump_lua_stack() (luaif/argvenvp.c), name says it all..
|
|
- Exec policy for scripts is now correctly selected when the script
interpreter is selected (things were messed up when the exec policy
had requirements for the interpreters..)
|
|
- There is new lua script: create_argvmods_rules.lua which
is used to create explicit rules based rules created by argvenvp_xxx.lua.
- Separated mangling rules for misc binaries to be in file
argvenvp_misc.lua
- Rules are generated by sb2 script and placed under
$SBOX_SESSION_DIR/argvmods/*.
Signed-off-by: Lauri Aarnio <Lauri.Aarnio@iki.fi>
|
|
- set name of the selected exec policy to an environment
variable before every exec, and also added a lua function
which locates the currently active policy (soon to be used
by the "devel"mode..)
|
|
- this commit adds support for exec policy based mapping of script interpreter:
A script interpreter can be selected based on location of the script.
For example, perl scripts from tools_root may map /usr/bin/perl to
tools_root, while perl scripts from the target_root can map /usr/bin/perl
to target_root.
- This commit does not contain changes to the mapping rules => everything
still works just as before (related changes to the "devel" mode will be
added by another commit)
|
|
Summary:
* Now it is possible to have several toolchains available simultaneously:
The primary gcc will be available as "gcc", while components of the secondary
toolchain(s) are available as "gcc-X.Y", etc.
* sb2-init now calls a new script, sb2-config-gcc-toolchain to set up
toolchain configurations
* Toolchain configuration variables were moved to new config files, two
files/toolchain
Some details:
- "sb2-upgrade-config" automatically upgrades existing config files
- "sb2-config-gcc-toolchain" was created by separating all target-gcc-related
actions from "sb2-init"; this was not as straightforward as it sounds.
All toolchain-related configuration variables had to be moved from
the old-style config file (sb2.config) to the new files, and then every
place where the variables were needed had to be checked. This turned out
to be more like a separation of siamese twins...but the result is that
it is possible to have more than one toolchain configured, finally!
|
|
- Older "libattr" libraries for ARM use an incorrect format for some
system calls; Maemo's patched qemu now has workaround for that. Now sb2
detects if the selected qemu knows about this "libattr hack" and
enables it if possible.
|
|
simple...
|
|
- Fix: exec parameters are now modified only when gcc tools are called from /usr/bin (previously the path was ignored, only basename was used to identify the tools) - Enhancement/fix: This includes support for rewriting paths like /usr/bin/gcc-3.4; sb2-init writes compiler version to the config files, so that exec preprocessing can register wrappers with version number for gcc, g++ and cpp - This patch also increments SB2's configuration file version number; sb2-init must be used to register gcc's version number to the config.files
|
|
|
|
new attributes "native_app_ld_library_path_prefix" and "native_app_ld_library_path_suffix" are available - "emulate" mode works better now when target architecture == host arch and libsb2.so has not been installed to target_root. (native applications, "emulate" mode)
|
|
With this commit it is possible to instruct sb2 to load localization
files and message catalogs from specific path (for example under
target_root).
(Reviewed by Lauri T. Aarnio)
|
|
now also handled by an exec postprocessor: Replaced that hard-coded logic what we had in sb_exec.c; all that is now handled by argvenvp.lua but the logic is still quite hard-coded and can't be controlled by an exec policy, yet. - "sb.getcwd()" was added to luaif.c, argvenvp.lua needs it - one more environment variable was removed (SBRSH_CONFIG)
|
|
mapping mode can now disable the cross-gcc toolchain by setting "enable_cross_gcc_toolchain" variable to false. - "emulate" mode does that now, because it should provide as accurate emulation of the target environment as possible (i.e. "gcc" must be executed from the target_root iff it has been installed to target_root) - previously "gcc" & other cross-toolchain commands were always mangled, and then execution failed because the path produced by exec preprocessing was mapped to target_root, which didn't contain the toolchain, of course..
|
|
|
|
Execution of target binaries (with qemu) is now handled by the exec postprocessor in lua_scripts/argvenvp.lua, just like what has been used for native binaries. - If the CPU transparency method is "sbrsh", postprocessing is not used, but the old code in sb_exec.c is still applied; this will be changed later by another commit - "sb2" script tests if the Qemu knows about "-0" and "-E" options; the exec posprocessor uses them if they are available: - option -0 is used to preserve exec semantics. Without it argv[0] will be overwritten with the file name (and it is not always the same thing) - option -E is used to inject environment variables to qemu's emulated environment. "prelink" won't work without this trick. both options were implemented for Maemo SDK+, and are present in their patched qemu. - These changes were originally written by Mika Westerberg and Pas
|
|
default ld.so (ld-linux.so) will loose argv[0], when the binary is executed by ld.so's command line (which is supportted by sb2). It will always copy the filename to argv[0]. - We now have a patch for ld.so which introduces a new option, "--argv0 argument", and a flag is used to tell to the lua scripts if a patched ld.so is available (the "sb2" script finds that out during startup phase). That patch is not included in this commit, but will be available soon..
|
|
|
|
SBOX_SESSION_DIR + a symlink in the session directory. SBOX_LUA_SCRIPTS variable still exists inside the "sb2" script, but it is not exported anymore.
|
|
not anymore load all mapping modes to memory, only the rules of the selected mode will be loaded. Rules will be copied to $SBOX_SESSION_DIR/rules.lua at startup. - There is a new "-M" option to sb2, which can be used to provide direct path to the mapping rule file (so that rules don't have to be under $SBOX_LUA_SCRIPTS/pathmaps anymore) - sb2 now creates a new configuration file, $SBOX_SESSION_DIR/sb2-session.conf That file will be used to pass per-session information about sb2's environment to the various child processes; we have had far too many environment variables in use. Currently "sbox_mapmode" is the only thing passed via the new file, but other environment variables will follow.. - This should have a positive effect on performance, too.
|
|
mapping modes than maemo do not yet contain exec policies, so the world is not yet ready for warnings about missing policies..
|
|
be used to define how native binaries are started: For example, the tools that are used from "tools_root" may need to load dynamic libraries from nonstandard locations and/or use a nonstandard ld.so; also, if the target architecture is the same as the host architecture, binaries may also need special settings and a special ld.so. - These features are off by default, but can be taken into use by installing a libsb2.so to tools_root (or to the rootstrap, if target arch.==host arch) - NOTE/WARNING: These features are currently off because the current ld.so (which is part of glibc) is not fully transparent to the application. See comments in the source for a longer explanation of this.
|
|
|
|
- the cross compiler is an optional feature now; if not specified to
sb2-init, all related commands ("gcc","as","ld",etc) will not be mapped
by the "argvenvp" exec argument mangling system, instead the commands
will be executed just as any other binary
- Now there are two ways to specify target architecture to sb2-init:
the "old way" autodetects it from the cross compiler, the second option is
to set it manually by a new command line option (-A).
|
|
Signed-off-by: Lauri Leukkunen <lle@rahina.org>
|
|
- added sb2logz, which extracts information from logs and produces summaries
- general: log format changed (each line now contains log level, too)
- *.c: log messages which are needed by sb2logz are now at INFO level
- interface.master & libsb2.c: Added gates to _exit() and _Exit(),
so that exit status can be logged
- sb_exec.c: bugfix: sb_execve_mod() returns nonzero if error, not zero
- sb2: location of log files changed: logs now go to ~/sb2_logs/,
and initial environment is printed to the log file
|
|
These changes allow use of a separate tool distribution when
using the "maemo" ruleset. Tested on Fedora 8 using Debian/sid
for tools.
Signed-off-by: Lauri Leukkunen <lle@rahina.org>
|
|
Cleans the sequence by pushing hashbang detection further down
the pipeline, improves code structure and hopefully fixes some
breakage.
Signed-off-by: Lauri Leukkunen <lle@rahina.org>
|
|
host-gcc is run with all manglings disabled
Signed-off-by: Lauri Leukkunen <lle@rahina.org>
|
|
sb_gcc_wrapper functionality is now implemented directly in libsb2.so as
a lua script directly managing the execve(file, argv, envp) call.
Same functionality can be used to do other things as well, see for
the dpkg-architecture example in lua_scripts/argvenvp.lua
Signed-off-by: Lauri Leukkunen <lle@rahina.org>
|
|
For now this is just a pass-through, doesn't do anything, but
from here it's just a matter of building up the lua scripts.
Signed-off-by: Lauri Leukkunen <lle@rahina.org>
|
|
The engine initialization will end up going through scratchbox_path2
so we have to have a "in process" state to know what to do.
Signed-off-by: Lauri Leukkunen <lle@rahina.org>
|
