Age | Commit message (Collapse) | Author |
|
|
|
This function returns the source position of a given address in the
program. If that address exists in an inline chain, then it also returns
the source positions that are in the chain.
|
|
This function returns a DIE object from the cache with the given offset
in the debug_info section.
|
|
This function returns the die object whose address range intersects
with the given address.
This function will also construct the DIE cache, if it hasn't been
constructed yet.
|
|
There is one cache that indexes DIE objects by the start address of
their range, and another cache that indexes by their offset in the
debug_info section.
Both caches are implemented with RedBlackTree, and are optional - they
will only be populated if 'build_cached_dies' is invoked.
|
|
In the current implementation, only DIE objects that are created via
DIE::for_each_child() will have parent offsets.
DIE objects that are created with CompilationUnit::get_die_at_offset()
do not currently store a parent offset.
We may improve this in the future, but this is enough for what we
currently need.
|
|
In some contexts, it's helpful to also know the "Attribute Form",
in addition to the "Attribute Type".
An example for such context is the interpretation of the
"DW_AT_high_pc" attribute, which has different meaning if the form
is an address or a constant.
|
|
We need to do this because the return address from a function frame is
the instruction that comes after the 'call' instruction.
|
|
It's a version of find_largest_not_above that returns an iterator.
|
|
This function returns the directory path & filename for a given file
index.
|
|
Previously, the LineProgram objects were short-lived, and only created
inside DebugInfo::prepare_lines() to create a vector of sorted LineInfo
data.
However, Dwarf::LineProgram also contains other useful data, such as
index-to-string mapping of source directories and filenames.
This commit makes each Dwarf::CompilationUnit own its
Dwarf::LineProgram.
DebugInfo::prepare_lines() then iterates over the compilation units to
prepare its sorted vector of lines.
|
|
This fixes an issue were some LibDebug objects (for example,
Dwarf::CompilationUnit) held a reference to their parent
Dwarf::DwarfInfo object, which was constructed on the stack and later
moved to the heap.
|
|
|
|
|
|
|
|
|
|
Steps to reproduce:
$ cat loop.c
int main() { for (;;); }
$ gcc -o loop loop.c
$ ./loop
Terminating this process wasn't previously possible because we only
checked whether the thread should be terminated on syscall exit.
|
|
This doesn't really matter in terms of writability for the kernel text
because we set up proper page mappings anyway which prohibit writing
to the text segment. However, this makes the profiler happy which
previously died when validating the kernel's ELF program headers.
|
|
We were incorrectly aborting property name enumeration after generating
names for all the indexable properties in the underlying string.
|
|
String objects are a bit special since the indexed properties are
overridden by the contents of the underlying PrimitiveString.
getOwnPropertyDescriptor() was not taking this into account, and would
instead return undefined when asked about an indexed property in a
String object.
|
|
|
|
|
|
|
|
Implemented IteratorComplete and IteratorValue, and sorted functions
based on their spec ordering.
|
|
|
|
|
|
|
|
|
|
This would allow assignments such as `let ...{ a } = { a: 20 }`
|
|
Instead, try to create the device objects in separate static methods,
and if we fail for some odd reason to allocate memory for such devices,
just panic with that reason.
|
|
|
|
By using to_numeric() and adding BigInt handling, we get support for
`Number(123n)`.
Fixes #8125.
|
|
|
|
|
|
|
|
- %GeneratorFunction%
- %GeneratorFunction.prototype%
- %GeneratorFunction.prototype.prototype%
- %Generator%.prototype
|
|
Because MD5 stored a "Bytes {}" wrapper to its internal data buffer,
it was not actually movable. However, its use in several parts of
the system (such as HashManager) assumed it was, leading to crashes.
Fixes #8135
|
|
Namely MD5, SHA1, SHA256, SHA384 and SHA512.
|
|
This ensures that the Array.prototype methods produce results using the
constructor of the derived object if it is one instead of always using
the default constructor.
|
|
This fixes the incorrect exception order and missing exception checks
that were caused by the implementation not conforming exactly to the
specification.
|
|
Stage 3 since August 2019 - we already have shebang stripping
implemented in js(1), so this removes it from there in favor of adding
support to the lexer directly.
Most straightforward proposal and implementation I've ever seen :^)
https://github.com/tc39/proposal-hashbang
|
|
Since we have had eval() for a while now, we can finally use it here -
this allows us to get rid of the confusing return statements in tested
source code.
|
|
|
|
This is initialized to be the same function object as the initial value
of the Array.prototype.toString generic function.
|
|
|
|
|
|
Fixes #7803.
|
|
This behavior might not always be desirable, and so this patch adds a
way to disable it.
|
|
|
|
|