Add backtrace functions for sandbox, including:
- os_backtrace() to collect addresses into a caller-supplied buffer
- os_backtrace_symbols() to convert addresses to symbol strings
- os_backtrace_symbols_free() to free the symbol array
The libbacktrace library (bundled with GCC) reads DWARF debug information
to provide detailed symbol resolution including function names (even for
static functions), source file paths, and line numbers.
The sandbox backtrace implementation wraps these OS functions to implement
the generic backtrace API (backtrace_init, backtrace_get_syms, etc.).
Enable it for just the 'sandbox' board. Add the library for the Rust
example too.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
It is possible to simply read the 'version_string' variable, but it
seems better to add a proper API call to get this. It is already
defined in lib/ulib/ulib.c
Add a prototype to u-boot-lib.h
Make use of it from the demo program.
Fix the comment for ulib_uninit() while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
We need to check for the ulib library before building any examples. Add
this and ensure that the examples are rebuilt if the library changes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add an example of a program which boots an OS by calling into the U-Boot
library.
Series-to: concept
Co-developed-by: Claude <noreply@anthropic.com>
Co-developed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Series-links: 1:28
The current Makefile for the ulib examples is not very easy to modify.
Split it into three parts:
- config.mk containing the variables used by the build tools
- a list of programs and the objects in each one
- rules.mk with some rules to make it all work
Use sys-objs to indicate objects which should be built with system
headers. Use U-Boot headers by default.
With this it is fairly simply to add a new program. Of course we could
make use of U-Boot's kbuild implementation to tidy this up, but the
purpose of the examples is to show how to do things outside the U-Boot
build system.
Co-developed-by: Claude <noreply@anthropic.com>
Co-developed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a test that checks that ulib operates as expected.
Add a .gitignore file for the executables thus created
There is a strange interaction with PLATFORM_LIBS which can cause the
examples to fail to build via 'make qcheck':
- CI runs 'make qcheck'
- the main Makefile sets PLATFORM_LIBS
- test/run calls test.py
- at some point test_ulib_demos() starts, with PLATFORM_LIBS set
- the test calls 'make' on examples/ulib/Makefile
- PLATFORM_LIBS is left alone, since it already has a value
- lSDL ends up not being in the link line
Thank you to Claude for helping to debug this and figure out the
PLATFORM_LIBS interaction.
Series-to: concept
Series-cc: heinrich
Cover-letter:
ulib: Complete initial U-Boot library
This series completes support for building U-Boot as a shared or static
library, enabling reuse of U-Boot functionality in external programs and
test suites.
The U-Boot library (ulib) allows developers to:
- Link against U-Boot functionality without a full U-Boot image
- Use U-Boot's OS abstraction layer, drivers, and utility functions
- Build test programs that can exercise U-Boot code in isolation
- Create applications that benefit from U-Boot's hardware support
Key features:
- Builds both shared (libu-boot.so) and static (libu-boot.a) libraries
- Preserves U-Boot linker lists for proper driver/subsystem init
- Configurable symbol renaming to avoid conflicts with system libraries
- Generated API headers with renamed function declarations
- Documentation and working examples
- Currently only supports sandbox architecture
The series includes:
- More build-infrastructure and Makefile integration
- Python-based mechanism for symbol renaming and API generation
- Test programs demonstrating basic library usage
- A simple example program showing real-world usage patterns
Symbol renaming ensures that U-Boot functions don't conflict with system
libraries. For example, printf() remains the standard library function
while ub_printf() provides access to U-Boot's printf implementation.
This is handled automatically during the build process.
The library excludes main() to allow external programs to provide their own
entry points while still accessing U-Boot functionality through ulib_init()
and ulib_uninit().
For example:
#include <u-boot-lib.h>
#include <u-boot-api.h>
int main(int argc, char *argv[])
{
if (ulib_init(argv[0]) < 0)
return 1;
ub_printf("Hello from U-Boot library!\n");
ulib_uninit();
return 0;
}
License implications are documented - the GPL-2.0+ license applies to
any programs linked with the library, requiring source code distribution
for compliant usage.
Future work will look at expanding support to other architectures.
END
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
It is possible to have some files that build in the system environment
and some in the U-Boot environment. To build for the system, the system
headers must be used, or at least have priority. For a U-Boot file, its
headers must be used exclusively.
Expand the Makefile example to have two files, one of which is built
using U-Boot headers. This shows how a program can be built which
straddles both domains.
Signed-off-by: Simon Glass <sjg@chromium.org>
