also errors when the buffer length is too small for the request buffer type.
basically tested, this is difficult to test without physical hardware.
this fixes#14966
Change-Id: Iebee5ff29dfe498ee52cab5867c8c4ff7d2bcde1
Reviewed-on: https://review.haiku-os.org/c/1484
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This resolves a bug where a collation pointer is
not being initialized.
Change-Id: Ice59f82eb6cedd3e15acbafa738445984d7114d3
Reviewed-on: https://review.haiku-os.org/c/1485
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I was doing some analysis of the memory areas the kernel was using
after a long uptime, and found that there were 1.3GB worth of
"slab area"s, but the kernel was "only" using 550MB according to
ProcessController ... but then I realized I wasn't looking at
swap, which showed another 700MB of usage.
So, adding it to ActivityMonitor's main memory graph seems to
make sense then. At least most Linux system monitors do this.
Without the MultiArchDirSetup, these would not use the boot cflags, and
end up being compiled position-independant. Of course, the a.out format
does not allow relocations, so this could not work.
Change-Id: I6bb570e545f1533200511e6881f71feedb77025b
Reviewed-on: https://review.haiku-os.org/c/1481
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
According to the IEEE standard documentation, the OpenFirmware entry
point should be in %o3. But that doesn't work, and both FreeBSD and
NetBSD expect it in %o4 (5th argument of the function). I suspect this
was changed for 64bit sparc, but neither the sparc nor 64bit
openfirmware specs mention it.
Move the sparc and powerpc specific parts out of the generic start.cpp
for openfirmware as they each have some specificities. More
specifically:
- sparc already clears bss for us
- entry point arguments are different
- determine_machine is of course platform specific
Change-Id: Icaa05087e88ea4d29198e3565223459aed75cdf9
Reviewed-on: https://review.haiku-os.org/c/1470
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I accidentally imported a newer version of the file that does the same
thing as the existing one.
Change-Id: Ifab3b24218f017cc57a459e0467cb8225accd9e5
Reviewed-on: https://review.haiku-os.org/c/1368
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The a.out format does not allow to handle this properly. So we need the
two sections to be contiguous.
Change-Id: I44455d4fb728bd47d5dcebc48c52b7d90d808104
Reviewed-on: https://review.haiku-os.org/c/1469
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- The entry point has to be at the start of the text section
- Use the correct formqt ("impure") for the a.out file
- Strip all symbols (the bootloader isn't relocatable)
Change-Id: I2b973c39eaf1416f874bf1b2668b1e3090eb5f7b
Reviewed-on: https://review.haiku-os.org/c/1468
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The list of categories for packages is currently
hard-coded into the HaikuDepot desktop
application. This change will change that so that
the list is obtained from the HaikuDepot Server
system and is always up to date with the server's
list of categories.
Change-Id: I757732f4d771e1599d6ad9c85cd65905640de928
Reviewed-on: https://review.haiku-os.org/c/1478
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
ia32intrin isn't supposed to be included, only x86intrin is,
but GCC 8 changed some of the __builtin definitions in a
backwards-incompatible way for some of the AVX headers.
So, this is a temporary hack until we are using GCC 8 syslibs
packages.
rpmalloc has now been turned on by default for over a week, and no
bug reports against it have been filed. So, it's probably safe
to remove this as dead code now.
Their copy constructors are exactly what GCC would generate,
but we can't remove them because doing so would make them
trivially copyable, and so they would be passed in registers
on x86_64, an ABI breakage.
So instead we have to add explicit casts to void* here.
The only non-POD types the macro is used on are BPoint, BRect, BSize,
and rgb_color, so the first change should essentially be a no-op.
The second change will technically have different behavior,
as the BMessenger copy constructor does not touch the _reserved_
field; but this shouldn't break anything, of course.
Unlike the last commit, I am not sure whether the memcpy/memsets
in here are properly safe to do. (They look OK, but a lot of them
involve template classes that probably should not make such
assumptions.)
But the code has worked so far, so let's disable the -Werror so
we can move forward with GCC 8 for now.
A lot of these classes are not *technically* "trivially copyable"
for one reason or another, but in all of these cases it seems
OK to me to use memcpy/memset on them. Adding a cast to void*
tells GCC that "I know what I'm doing here" and shuts up the
warning.
These worked in identical fashion to what the default copy
constructors would be, but their mere presence marks the class
as being "non-trivially copyable," which means that memcpy'ing
it is now a -Werror on GCC 8.
We have to be careful when making this change, though: classes
which *are* trivially copyable can be passed inside registers
on x86_64, so changes like these break ABI in a dangerous way.
These classes is private, so it should not be a problem, but
for other classes (e.g. BRect, BPoint) we cannot fix them
properly right now.
It warns on snprintf's output "possibly" being truncated (e.g.,
two B_PATH_NAME_LENGTH chars being concatenated together) which may
be exactly the behavior the programmer wanted. So that's not very
helpful.
I am unable to reproduce the problem locally, but
suspect that the lack of locking around one line
may be the cause. Hopefully fixes#14025.
Change-Id: I14ba6d2cb4f264af732fad9c783c55f690cece4f
Reviewed-on: https://review.haiku-os.org/c/1472
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Follow-on changes from recent commit of the same title
with some improvements and fixes.
Change-Id: Ic4439966340578b920345332669591f6cdfcc203
Reviewed-on: https://review.haiku-os.org/c/1471
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
should help for ports.
Change-Id: Id504bdb79cb68db4b615f58848e0e1a86ced8d2b
Reviewed-on: https://review.haiku-os.org/c/1467
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This also means that when attach fails, we destroy the root device.
This should fix stale root devices getting left around when attach
fails.
Probably helps with or even outright fixes#15016.
add-ons" is set.
Confirmed to fix#14361. It is finally possible to un-brick an install
with a bad system library in non-packaged without having to use another
install to do so.
Change-Id: Iafea7821f02cb34e77c766b1f97d1c19206b1081
Reviewed-on: https://review.haiku-os.org/c/1452
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Allows to make the scrollback visible again when resizing, instead of
adding blank lines at the bottom.
Change-Id: I7a14188cdcb14bcd197325b935d8cfe2435ae80f
Reviewed-on: https://review.haiku-os.org/c/1464
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This adds an average overhead of 10-15 us, which seems acceptable
(without the previous patch it adds 200-250 us, which is less so),
and it makes "listarea" output much more enlightening for applications
like app_server or WebKit which use a lot of them.
Change-Id: I48a4148e6e9fb0d1a8bbf67294deeafad9372f44
Reviewed-on: https://review.haiku-os.org/c/1462
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
If the caller does not want the symbol name/address/etc., we don't
need to spend the time finding it, and can just return after
finding the image.
Change-Id: I138f8bd4071ffc25738dac4d6c0c6d3fe25edf1c
Reviewed-on: https://review.haiku-os.org/c/1461
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
On 32-bit at least, our ASLR is too aggressive and fragments
the address space very quickly to the point where at 500MB (1/4)
usage, area insertion begins to fail.
We want applications to be able to handle out-of-memory
conditions gracefully, not just trigger an assert every time.
I disabled this before, looks like I missed it in the final
patch.
The Device object gets an ID before it begins initializing, and
loses its ID after it fully finishes tearing down, so simply
verifying the Device object is non-NULL is not enough to verify
that we can use it. We need to call InitCheck() every time.
In Device itself, we should also unset fInitOK when beginning
teardown, so that anyone who still has a handle can no longer
use this Device object while teardown occurs (which, depending
on the number of pipes, pending transfers, etc. may take some
time.)
Fixes#14949 and almost certainly any other USB-related KDLs
in these codepaths.
