This way, they are available by default when not using a strict
language standard version.
The change is applied to all architectures (except m68k, which doesn't
define them at all).
Fixes#19534
Change-Id: I71238919e50518abaa65fa20365c912a577e3455
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9196
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
Add support for using `RTLD_NOLOAD` with `dlopen` on Haiku.
While not specified in POSIX, this option is widely available (both
GNU/Linux and BSD) and is the only way to atomically check if a shared
object has been loaded.
Change-Id: I061332307d76c84f6a2abb6f92c4ed964bd90a1e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9161
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
This is unused but defined in Darwin, BSD, and Linux.
It allows developers to feel good about specifying that they want to map
a file (which is the default behavior anyway). The value is 0, so
specifying this flag does not have any effect.
This allows to more easily compile code that uses the flag.
Change-Id: I7a880a3090d90b7e8cef5144e82f71beb61147a8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9152
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Actual blending mode writing is still disabled for now. According to
previous commit messages it cause problems with BView::Begin/EndLayer
API.
Change-Id: Ib3c58b05a949e556e9f14a57822b20cd259e12d4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8559
Haiku-Format: Haiku-format Bot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Tested-by: Commit checker robot <[email protected]>
ElfW(x): to automatically use the relevant Elf32 or Elf64 type for the
current system
NT_GNU_BUILD_ID: constant defining the GNU "build ID" note in ELF files.
WebKit uses both of these to store info in javascript object caches, so
it can detect if the same version of WebKit is being used and the cache
can safely be reused, or if it should be reconstructed.
Change-Id: Ia9eccc1acc79ac4982b87609d2815c4a611e4176
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9143
Reviewed-by: nephele nephele <[email protected]>
We can't rely on it not changing between calls, especially as
MaxUpdateTextWidth() changes the value and re-gets it, and
that's called at the end of this method always. So we need to
keep our own copy rather than using the one that's owned by
the subclass.
Fixes a use-after-free uncovered by the guarded heap in VolumeSlider,
reported in #19493.
It accesses values through macros, so just write functions that
fetch the appropriate value from Haiku's structures.
Note that the values for multibyte digit characters are hardcoded.
As far as I can tell, we never set or updated these in glibc's
locale structures, so it always just used the default, so this
should not be a behavioral change from before.
Otherwise it needs to use libio internals to implement these,
which we don't want. musl also exports all these methods for
the same reason.
Implementations taken from glibc 2.15, current gnulib (5077f67), and
in a few cases tweaked for better Haiku support.
Should fix#19479.
* Take it from upstream glibc 2.15, much closer to the version we use.
* Drop fpurge from stdio.h, it's nonstandard. Keep it around for
ABI compatibility for now (BeOS didn't have it.) __fpurge is left
in stdio_ext.h.
See inline comment: otherwise we could deadlock waiting for busy pages.
At the same time, make page_faults_allowed just an int16 and drop
atomics and extra checks, they aren't needed.
Fixes#19441.
Change-Id: I1b7cc06f66b44c3520fa36497c076ee5a6320706
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9120
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
It's in POSIX-2024. Remove the libgnu implementation and just import
the changes from latest FreeBSD (dc36d6f9bb1753f3) instead.
While at it, put the non-standard sort functions behind
_DEFAULT_SOURCE.
Unfortunately there are some marked "public" that also use it,
so we can't just move the remainder to an internal file and then
drop libio.h from public consumption.
Delete all the unused portions of the public libio.h while at it.
Adjust the two legacy stdc++ headers that still included it;
it seems they didn't themselves depend on any of the definitions it
contained. However, streambuf.h actually did, so put that definition in
libio.h so that it's always present.
(The stdc++ implementation will get the 'real' _G_config.h from
libroot glibc.)
It's set in _G_config.h, but this file doesn't include that,
so in many cases the "unlocked" function was called instead.
(Most of the stdc++ .cc files did have it set, though.)
It's needed by GCC2 stdc++, but we shouldn't be including it
for all consumers of <stdio.h>, which we were. Drop it,
and adjust all the things that were relying on <stdio_pre.h>'s
definition of __PRINTFLIKE to use the _PRINTFLIKE defined
in BeBuild.h instead.
Hopefully should not cause any breakage; the libroot
implementation of __freading depended on this, but
I didn't see anything else which did.
"int" of course is also an abbrevation for "integer", so having
two abbreviations is sometimes confusing. The BeOS functions
just use "interrupt" (e.g. "install_io_interrupt_handler"); it
seems we inherited the "int" abbreviation from NewOS.
The basic kernel methods and files related to interrupts are
here adjusted to drop the abbreviation and just use "interrupt(s)".
The architecture-specific functions ("arch_int_*") are mostly
moment left alone for now, though of course architecture-specific
usages of the generic kernel methods are adjusted.
Change-Id: Ic113ea1280a3c78e25f8ca3cc55b24ed5f594eae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9119
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
The XSAVE area can be quite large (1-2KB+), so rather than always
putting it on the kernel stack, just use the arch_thread FPU state.
Change-Id: Ie64c3ea3ca52cd8a4425ae1da69792588a69832a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9090
Reviewed-by: Jérôme Duval <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
This reverts most of c7360f4b02.
Unlike the other floating-point registers, these values are callee-saved
(see "System V Application Binary Interface, AMD64 Architecture
Supplement" section 3.2.1.) So we need to preserve their values and not
reset defaults on context switch.
EMMS, as the previous changes used, does not suffice to clear
exceptions. We could use FNCLEX instead, but we need to reset
x87 state on context switch anyway, so use FNINIT. Do not
reinstate FNCLEX in the exception handler since it will
be executed on context switch anyway.
We also need to ensure a clean initial state, so take care of that
in arch_thread_init.
See also:
* remarks in 396b74228e
* as well as 53e2dc0f85Fixes#19454 and #18624. Doesn't regress #18656 and #19063.
Doesn't seem to affect #19450.
Change-Id: I7179f1ec7304e7aed09ff80f6773e53d5dbdf5f9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9081
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This change will allow the BColumnListView to have
multiple rows added or removed at the same time.
Without this, applications using the BColumnListView
will need to add and remove rows one by one which,
for longer lists with complex columns, is a
performance problem; an example being HaikuDepot.
Note that this change does not amend the formatting
style on the class's source.
Change-Id: I72303c8b069b686251c3a65af7ae45c8884d5637
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9056
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Andrew Lindesay <[email protected]>
Fill/StrokeBezier always have 4 points so passing point count is not
needed. Point count is not passed to BView drawing API and not stored in
BPicture data.
Change-Id: Iddb32bd493143d4450acfb76bdc56fc02136448e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8560
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
This cleans up a lot of subtle or hidden inconsistencies:
* Drop the "exactAddress" parameter. It was added in hrev15708 (2005),
but all callers in all bootloaders passed "false" to it until 2022,
when one codepath in the ARM32 EFI loader started using it.
* Adjust EFI's platform_allocate_lomem to platform_allocate_region_below,
and add a platform_assign_kernel_address_for_region(). This allows the
aforementioned ARM EFI codepath to continue to do what it wants,
which is to get an identity-mapped trampoline page, without having
functions with confusingly different semantics ("allocate_lomem"
assigned the virtual addresses as identity-mapped unconditionally,
but it didn't insert these into the virtual allocated ranges.)
This also paves the way for other EFI loaders to use this method
to allocate memory below whatever default the boot services
would give us.
* Drop fixed virtual address allocation for all arches on EFI, with the
exception of fixed addresses inside KERNEL_LOAD_BASE, same as on
other boot platforms. Anything which wants fixed virtual addresses
outside that region can use the new "assign kernel address" method.
* Validate kernel base and size against kMaxKernelSize, instead of
assuming it fits. This matches behavior of other boot platforms.
Ideally we would have some more generic routine for mapping the
kernel, but this suffices for now.
Tested with x86_64 and ARM; both still boot (well, ARM boots as
far as it did before this commit, anyway.)
Change-Id: Ieb4fba752994101191a2335cb5395eb2b726fcbb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9024
Reviewed-by: waddlesplash <[email protected]>
_Uninstall() before _Hide() in BMenu because the window must
be available when we _Uninstall() especially for shortcuts.
Remove #define and always assume USE_CACHED_MENUWINDOW.
_Uninstall() whenever we _Hide() in BMenu.
Change-Id: I5dae85f6edf1f0b4ccf67a6d9d77470576671cee
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9012
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This replaces the non-functioning "Network password" option that was
never implemented.
Change-Id: I9b7362f4e05d7f1a4be321e1a9aade62559794d2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9009
Reviewed-by: waddlesplash <[email protected]>
We use the TSC to measure the APIC frequency, but the TSC frequency
is only fully initialized in the kernel (where it's read from CPUID
on recent hardware).
Furthermore, on some more recent systems, it seems there may only be
X2APIC and no MMIO APIC timer at all, and the bootloader does not
handle that case.
The method in the kernel uses spin() instead of a fixed instruction
count as well as system_time_nsecs() and a double for (hopefully)
more accurate calibration.
At least on VMware, this method seems more accurate: the APIC frequency
read from the hypervisor CPUID leaf is 66,000,000; the old method in
in the bootloader yielded values like "65,801,075" and "65,106,382",
while the new one yields values like "65,963,920" and "65,962,580"
(those pairs of values are from two consecutive boots.)
The difference was sometimes similar (but smaller as a percentage) in
QEMU with software emulation: e.g. "993,218,085" vs. "992,965,761". But
sometimes it wasn't: e.g "991,619,585" vs. "993,689,669". (QEMU in
software mode doesn't report a frequency via hypervisor CPUID leaf.)
Change-Id: I4fb8535d1d984f13867e2f84e7dfad1ceed42c13
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8999
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
* PagesAllocator: A process-global caching strategy for the allocator.
It deals with allocating virtual addresses and memory, and gives us
back some of the performance that's lost by having an actual
decommitment strategy (which the hoard2 glue code doesn't.)
It uses two SplayTrees to manage free lists, and resizes areas
on allocate if they aren't next to a free chunk (which saves a lot of
time for large reallocations.)
There's still room for improvement here, see inline TODOs. But overall
we get pretty good performance with it.
* Add a TLS slot for the allocator glue to use. Right now it just puts
integers in there (since thread IDs are not evenly distributed),
but we could put a data structure pointer in there as well, potentially.
Change-Id: I56ddb0b022a468dc04275075ed7e174b339c8ca4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8335
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
We always did under EFI but not under BIOS. Now, the BIOS loader
reports the root pointer as well, so we don't need to find it again.
Change-Id: Ie83adb53f098d44f2688a1a327c084f94afa2673
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8941
Reviewed-by: Fredrik Holmqvist <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
The shortcut detection was working, just not the display of the
modifiers in the menu. I've added back the necessary code to fix
this in BMenuItem.
BWindow does the heavy lifting of preparing the keys and
modifiers. I have changes _FindShortcut() used by BMenuItem to
send the prepared modifiers back to BMenuItem.
Set the parameters raw in the constructor, they will get fixed
up in Install().
I also make sure to use the prepped version of the key and mods
in BWindow::AddShortcut() to remove the old one. This is a minor
update that eliminates an edge failure case of malformed input.
Fixes#19395 a regression from hrev58589.
Change-Id: I4333f89149ff843f92dbffbd53d58ffc2def6760
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8943
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: John Scipione <[email protected]>
Since BObjectList is a template class, this only breaks ABI where
BObjectList was exposed in public methods, and even then it's only
a name mangling break and we should be able to add compatibility
methods if necessary.
(The old "bool owning" member variable is left intact for ABI
compatibility, for the moment, though it's otherwise unused now.)
Tracker's PoseList is the only remaining type that has a "bool owning"
switch in the constructor rather than template parameters.
This should significantly improve the output of static code analysis
tools that previously detected list operations as causing use-after-frees
and double-frees, as well as make code maintenance easier by making it
easier to determine what list owns (or does not own) an object.
It should also be a minor performance optimization, since the branches
for calls to delete/free should now be optimized out altogether.
Still boots to desktop and Tracker, Deskbar, Debugger all tested
and verified as working.
Change-Id: If2a24a6f0d22e7a506ef554fcfdd328907279ed4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8915
Reviewed-by: waddlesplash <[email protected]>
This is to make BMenuBar and BMenu margins the same.
The hardcoded menu item margin numbers come from this math on what the
BMenu and BMenuBar item margins respectively used to be a long time ago:
14 - 8 = 6 // for left margin
(14 + 20) - (8 + 8) = 18 // for left + right margin
We have since updated these margins so they need to be recalculated.
Use BPrivate::MenuPrivate to get the new margin deltas.
IconMenuItem and ModelMenuItem classes are used by Tracker add-ons and
those can be in the menu bar as well.
Change-Id: Ie4147c31e6b19764cb36b9c414f7e91c47b7d9bd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8905
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Make it clear that this enum just defines ASCII control characters, and
there is no 'free space'. Also add comment showing which key combination
produces each control character.
Change-Id: I01884132842281cce6c13dd9398b1aeddadae58a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8899
Reviewed-by: nephele nephele <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
captain0xff