The stack base and end addresses are stored in TLS slots that are
prepared when enabling stack traces and filled in lazily on use for
each thread. This avoids the need of calling get_thread_info to get
these values.
Also simplifies the code somewhat due to proper frame skipping support.
It can be used to get a stack trace of the current thread. Note that
this works by walking frame pointers and will not produce anything
useful if an application is compiled with the frame pointers omitted.
The stack base and end addresses have to be provided as arguments and
are used to check that the frame pointers fall within that range. These
values are thread specific and can be retrieved with get_thread_info().
No other sanity checks (like checking for loops in the linked list) are
done.
This is a simplified rewrite of the stack trace code from the kernel
debugger.
As this code is common to x86 and x86_64 but is not generic across
architectures I introduced x86_common as a directory to put such
sources.
Extend the get_nearest_symbol_at_address() private runtime_loader
export to include imageName and exactMatch arguments.
The imageName holds the SONAME of the image, if available, so cannot
neccessarily be extracted from the image path.
Whether or not there was an exact match, i.e. the symbol with its size
contains the address, is now returned in exactMatch.
This adds libroot_guarded.so to the HaikuDevel package. It is the same
as libroot_debug with the debug heap swapped out for the guarded heap.
The guarded heap has some useful features that make it desirable to use
while having the disadvantage of a large memory and address space
overhead which make it unusable in some situations. Therefore the
guarded heap cannot simply replace the debug heap but should still be
made available. As the heap init needs to happen even before having
environment variables, the heap to use can not be chosen dynamically.
Exposing them through their own libraries is the next best thing.
When enabled (using heap_debug_dump_allocations_on_exit(true) or
MALLOC_DEBUG=e) this causes a dump of all remaining allocations when
libroot_debug is unloaded. It uses terminate_after to be called as
late as possible.
When combined with alloc stack traces this makes for a nice if a bit
crude leak checker. Note that a lot of allocations usually remain
even at that stage due to statically, lazyly and globally allocated
stuff from the various system libraries where it isn't necessarily
worth the overhead to free them when the program terminates anyway.
When configured to do so (using heap_debug_set_stack_trace_depth(depth)
or MALLOC_DEBUG=s<depth>) the guarded heap now captures stack traces on
alloc and free.
A crash due to hitting a guard page or an already freed page now dumps
these stack traces. In the case of use-after-free one can therefore see
both where the allocation was done and where it was freed.
Note that there is a hardcoded maximum stack trace depth of 50 and that
the alloc stack trace takes away space from the free stack trace which
uses up the rest of that maximum.
The get_stack_trace syscall generates a stack trace using the kernel
debugging facilities and copies the resulting return address array to
the preallocated buffer from userland. It is only possible to get a
stack trace of the current thread.
The lookup_symbol syscall can be used to look up the symbol and image
name corresponding to an address. It can be used to resolve symbols
from a stack trace generated by the get_stack_trace syscall. Only
symbols of the current team can be looked up. Note that this uses
the symbol lookup of the kernel debugger which does not support lookup
of all symbols (static functions are missing for example).
This is meant to be used in situations where more elaborate stack trace
generation, like done in the userland debugging helpers, is not possible
due to constraints.
For it to be available we build malloc_debug in C++11 mode when not
using GCC2. Note that max_align_t is not in the std namespace in GCC4
versions prior to GCC 4.9. The extra "using namespace std" is there to
be forward compatible once we update.
These were here for debugging purposes, as often it is a sign of
inconsistencies. However, for USB disks this is a normal occurence
when someone janks out of the device without unmounting first.
Make sure we log these cases though, as it still helps debugging.
Fix sponsered by http://www.izcorp.com
This allows for something similar as was implemented in 217f090 but
makes it optional and configurable.
The MALLOC_DEBUG environment variable now can take "a<size>" to set
the default alignment to the specified size. Note that not all
alignments may be supported depending on the heap implementation.
This reverts commit 217f090f9e.
At least for the guarded heap this completely defeats the purpose. If
software requires a certain alignment it should request it using
memalign explicitly instead of assuming it.
* based on current glibc sysdeps/nptl/bits/libc-lock.h file.
* include missing headers which were previously included by libc-lock.h.
* This fixes#11182.
* drop my fdt tests
* we have to call fdt parsing code *after* cpu_init (why?)
* pass fdt pointer to all FDT support calls to avoid confusion
once we get into the kernel land
* look for PL011 compatible uart and use it
* Add some saftey checks to serial putc code to avoid null*
* fdt_node_check_compatible returns 0 on success not 1
* fdt_get_device_reg needs to add the SOC base to the result
* fdt_get_device_reg might need to add the second range cell
instead of reg?
The comparison to decide whether or not to reuse the name buffer when
renaming a rootfs entry was reversed. For renames where the new name
was longer than the old one this resulted in writing beyond the name
buffer and corrupting random kernel memory.
A likely candidate for this to be triggered was when a audio cd was
renamed due to a CDDB lookup, as the placeholder "Audio CD" is quite
short and the actual CD name is usually longer.
Fixes: #10259. Possibly fixes the related #9528 and #9858.
* Move more code into fdt_support
* We now can query FDT registers based on name or alias
* Return addr_t where it makes sense
* Copyright change ok'ed by mmu_man
* This isn't be best long-term place for this code,
will likely move to some generic FDT support code.
* We pass a path like "/soc/gpio" and get back the
base physical register address in memory minus
the range offset.
* The existing code set the first available pa and va to
the end of the page dirctory.
* The arm mmu code was attempting to identity map (va==pa)
the memory, but also wanted memory to be in kernel space.
This allocation method isn't possible on all boards
(including the pi)
* We're adjusting the dynamic ram to KERNEL_LOAD_BASE
plus the max size of the kernel. (which is what most
other platforms are doing)
* The Raspberry pi 2 uses a new SoC which differs slightly
from the Raspberry Pi 1.
* Someday these two board targets could go away when we get
FDT support.
* To while there was some compatibility between
BCM2708 and BCM2805, it makes the BCM2806 changes
more confusing. We don't have any valueable BCM2708
targets.