POSIX says, "Conforming applications should not assume that the returned
contents of the symbolic link are null-terminated."
If we do include the null terminator into the returning string, Python
believes it to actually be a part of the returned name, and gets unhappy
about that later. This suggests other systems Python runs in don't include
it, so let's do that too.
Also, make our userspace support non-null-terminated realpath().
This "mutes" output from dbg() calls - which is not an issue inside
serenity itself but if the script is run on the host machine and stdout
and stderr are displayed in the same terminal window.
Assert that the source/destination address is in kernel space when
appropriate. This is mostly to give ourselves an error if we're doing
something we were not expecting to be doing.
The addition of assert functions to Userland/js
was done before we had load(..) implemented. Now
that it exists, it seems like the right move the
test helper functions to pure javascript instead
of poluting js with random global functions.
Output address validation should be done for the tracer's address space
and not the tracee's.
Also use copy_to_user() instead of copy_from_user(). The two are really
identical at the moment, but maybe we can add some assertions to make
sure we're doing what we think we're doing.
Thanks to Sergey for spotting these!
Previously, a breakpoint was removed after it was tripped.
After a breakpoint trips, we have to undo the 'int3' patch
from the instruction in order to continue the exceution.
To make a breakpoint persist, we switch to "single step" mode,
which stops the execution after a single instruction, and then we
insert the breakpoint at the previous instruction.
There is also some code that deals with an edge case where there are
breakpoints in two consecutive instructions.
We currently only care about debug exceptions that are triggered
by the single-step execution mode.
The debug exception is translated to a SIGTRAP, which can be caught
and handled by the tracing thread.
For some reaason, some magic is required to convince gcc to give us
the implementation for "__cxa_demangle"
Thanks @predmond for finding this simpler form of magic :)
Meta/Lagom/build seems to be the expected cmake output directory.
(It's hardcoded in Libraries/LibJS/Tests/run-tests.)
Add it to the project .gitignore
This memory range was set up using 2MB pages by the code in boot.S.
Because of that, the kernel image protection code didn't work, since it
assumed 4KB pages.
We now switch to 4KB pages during MemoryManager initialization. This
makes the kernel image protection code work correctly again. :^)
Since declarations are now hoisted and handled on scope entry, the job
of a VariableDeclaration becomes to actually initialize variables.
As such, we can remove the part where we insert variables into the
nearest relevant scope. Less work == more speed! :^)
"var" declarations are hoisted to the nearest function scope, while
"let" and "const" are hoisted to the nearest block scope.
This is done by the parser, which keeps two scope stacks, one stack
for the current var scope and one for the current let/const scope.
When the interpreter enters a scope, we walk all of the declarations
and insert them into the variable environment.
We don't support the temporal dead zone for let/const yet.
Instead of using a separate synchronization variable, just use the lock
holder TID for synchronization. This way, we only need to CAS when
first acquiring a lock.
Since the FlyString deduplication mechanism uses a HashTable, we know
that any StringImpl inside a non-null FlyString will already have its
lazily computed hash.
Instead of pushing the message, file name, line# and function name
separately, we now mash the message, file name and line# into a string
constant and pass that.
This means that the failure path only has to push a single address onto
the stack, reducing the code size and causing the compiler to inline
many more functions containing an assertions (e.g RefPtr::operator*())
Obviously if you wanted minimal size, you could turn assertions off
entirely, but I really like running with assertions, so let's make
a little effort to reduce their impact. :^)
The MDN example for creating a custom error type in javascript uses:
function CustomError(foo, message, fileName, lineNumber) {
var instance = new Error(message, fileName, lineNumber);
instance.name = 'CustomError';
instance.foo = foo;
Object.setPrototypeOf(instance, Object.getPrototypeOf(this));
return instance;
}
The name property on the Error prototype needs to be settable for
this to work properly.
The work I did to add assert as a native function in js
was a step in the wrong direction. Now that js supports
load() it makes sense to just move assert and anything
we want to add to the test harness into pure javascript.
