The dynamic loader exists as /usr/lib/Loader.so and is loaded by the
kernel when ET_DYN programs are executed.
The dynamic loader is responsible for loading the dependencies of the
main program, allocating TLS storage, preparing all loaded objects for
execution and finally jumping to the entry of the main program.
This adds an allocate_tls syscall through which a userspace process
can request the allocation of a TLS region with a given size.
This will be used by the dynamic loader to allocate TLS for the main
executable & its libraries.
When the main executable needs an interpreter, we load the requested
interpreter program, and pass to it an open file decsriptor to the main
executable via the auxiliary vector.
Note that we do not allocate a TLS region for the interpreter.
This command outputs the memory contents of a given address as an
unsigned int.
LibDebug already had support for this, so just a matter of intergating
it in sdb.
Very useful :)
Previously, we only accepted addresses that started with digits
'0'-'9', which was not correct because we expect addresses to be in
base 16.
We now expect addresses to be written with '0x' prefix, e.g 0xdeadbeef.
From the spec: https://tc39.es/ecma262/#sec-punctuators
OptionalChainingPunctuator ::
?. [lookahead ∉ DecimalDigit]
We were missing the lookahead and therefore incorrectly treating any
'?.' as TokenType::QuestionMarkPeriod.
Fixes#4409.
FileManager windows now alternate between the old-style location text
box and a new-style breadcrumb bar. The location bar shows up when you
try to edit the location (with Ctrl+L) and disappears once the textbox
loses focus.
The textbox and breadcrumb bar are mutually exclusive to keep it tidy.
If a hook triggers the deletion of the GUI::Button, we would be unable
to proceed in a well-defined manner here, so let's protect ourselves.
This probably needs to be done in a whole lot of places, since GUI
widgets are just ref-counted Core::Objects and running arbitrary code
can mean that they get deleted.
Let's start moving away from using raw strings for CSS identifiers.
The idea here is to use IdentifierStyleValue with a CSS::ValueID inside
for all CSS identifier values.
Parse out the font-family, font-size and font-weight values from CSS
and use them to perform a kinda-best-effort lookup against the system
font library.
We also now handle standard font names like "sans-serif", "monospace"
and others.
Now that documents are attached to their frame *before* parsing, we can
create the content frame of <iframe> elements right away, instead of
waiting for the host frame attachment.
Fixes#4408.
This patch adds a second style dirty bit that tracks whether a DOM node
has one or more children with dirty style. This allows the style update
to skip over entire subtrees where all nodes are clean.
Undefined length values can default to auto in all length boxes and
we'll get the values we need. This saves us from having to deal with
undefined lengths later on in layout.
At some point we should break the style application process into
a few more formal steps, but this at least simplifies some things.
This fixes an issue where TCP sockets could get into the Established
state too quickly and fail to unblock a subsequent sys$select() call.
This makes websites load *significantly* faster. :^)
Now that we attach the document to the frame before parsing, we have
to make sure we set the encoding on the document before parsing, or
things may not turn out well.
Instead of asserting when you call TextCoded::decoder_for() with a
non-standard encoding name, let's be nice and see if we can't find a
decoder for the standardized version of the encoding name.
FrameLoader now begins by constructing a DOM::Document, and then builds
a document tree inside it based on the MIME type. For text/html we pass
control to the HTMLDocumentParser as before.
This gives us access to things like window.alert() during parsing.
Fixes#3973.
After you mark a node as needing new style, there's no situation in
which we don't want a style update to happen, so just take care of
scheduling it automatically.
Almost everyone using this API actually wanted String instead of a
ByteBuffer anyway, and there were a bunch of slightly different ways
clients would convert to String.
Let's just cut out all the confusion and make it return String. :^)
