History log of /gem5/src/base/loader/dtb_object.cc
Revision Date Author Comments
# 11793:ef606668d247 09-Nov-2016 Brandon Potter <brandon.potter@amd.com>

style: [patch 1/22] use /r/3648/ to reorganize includes


# 11761:285cab6580a7 09-Nov-2016 Brandon Potter <brandon.potter@amd.com>

base: remove header file to prevent a macro name collision


# 11392:5967db4cff04 17-Mar-2016 Brandon Potter <brandon.potter@amd.com>

base: add symbol support for dynamic libraries

Libraries are loaded into the process address space using the
mmap system call. Conveniently, this happens to be a good
time to update the process symbol table with the library's
incoming symbols so we handle the table update from within the
system call.

This works just like an application's normal symbols. The only
difference between a dynamic library and a main executable is
when the symbol table update occurs. The symbol table update for
an executable happens at program load time and is finished before
the process ever begins executing. Since dynamic linking happens
at runtime, the symbol loading happens after the library is
first loaded into the process address space. The library binary
is examined at this time for a symbol section and that section
is parsed for symbol types with specific bindings (global,
local, weak). Subsequently, these symbols are added to the table
and are available for use by gem5 for things like trace
generation.

Checkpointing should work just as it did previously. The address
space (and therefore the library) will be recorded and the symbol
table will be entirely recorded. (It's not possible to do anything
clever like checkpoint a program and then load the program back
with different libraries with LD_LIBRARY_PATH, because the
library becomes part of the address space after being loaded.)


# 11189:4237221d3e31 06-Nov-2015 Andreas Hansson <andreas.hansson@arm.com>

misc: Appease clang static analyzer

A few minor fixes to issues identified by the clang static analyzer.


# 10880:61a56f76222b 03-Jul-2015 Curtis Dunham <Curtis.Dunham@arm.com>

base: remove fd from object loaders

All the object loaders directly examine the (already completely loaded
by object_file.cc) memory image. There is no current motivation to
keep the fd around.


# 10508:aa46a8ae3487 30-Oct-2014 Ali Saidi <Ali.Saidi@ARM.com>

arm: Fix multi-system AArch64 boot w/caches.

Automatically extract cpu release address from DTB file.
Check SCTLR_EL1 to verify all caches are enabled.


# 9538:182d67b5b57a 15-Feb-2013 Anthony Gutierrez <atgutier@umich.edu>

loader: add a flattened device tree blob (dtb) object

this adds a dtb_object so the loader can load in the dtb
file for linux/android ARM kernels.