* For tracking, there are *mega* hacked together using
llvm's linker and functionality isn't a sure thing.
* Thanks waddlesplash for the sketchy changes :-)
* Hopefully gets non-bootstrap arm builds working again
and let us work on the toolchain without blocking arm
development.
Change-Id: I0617ed83cc757d098e6464222405f75eed91196e
The last time someone touched this directory, there was no floating
point support configured in ARM. Now we are targeting ARMv7a+, which
always has a hard FPU, so we need this now.
With this, a haiku.hpkg can (finally) be built again (at least
under lld, anyway!)
I am using this to use clang+lld for linking on ARM builds,
which seems to be more tolerant than binutils ld is, and
gets the build a bit farther for now.
The previous hack, which as the comment (and __MWERKS__) implies
dates all the way back to the Be era, finally broke: int32 is "int"
on non-x86, not "long", and so this generated an undefined symbol
error on ARM.
The best solution seems to be to make StartMenuBar merely protected,
and then make a subclass where it is fully public to call it.
This is a lot less fragile (and much less ugly.)
Change-Id: I0519d0d9eeb1cc4523d0c6dd4fdfe8688ed1092c
Reviewed-on: https://review.haiku-os.org/c/1516
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The changes in this commit are large but also subtle, so
an explanation of how they came to be seems to make sense:
Earlier today I tried booting Haiku on QEMU under USB3 ... and
discovered that it didn't work, with the "Operation timed out"
message from in usb_disk upon failing a data transfer. Indeed,
turning on tracing showed no event was being posted for the
transfer. So, I downloaded QEMU's source code, turned on XHCI
debugging, and began tracing what was going on.
Eventually I determined by adding more and more printfs into QEMU's
XHCI implementation that what was occuring was that it was evaluating
a Link TRB, hitting an empty TRB, and then deciding that the TD (aka.,
the "run" of TRBs) was not ready to be consumed, and bailing.
In fact, that very condition (a link TRB leading to an empty TRB)
is precisely what _LinkDescriptorForPipe did before this commit.
We allocate only a small (8 before this commit, 16 + 1 after this
commit) TRB ring for each *endpoint*, and larger ones on a per-*transfer*
basis; and just write Link TRBs onto the Endpoint ring pointing to
the transfer TD, and then one at the end of each transfer TD leading
back to the endpoint ring.
The reason this occured inside usb_disk, and not earlier (e.g.
during descriptor fetching), is that QEMU has special logic around
determining transfer lengths of control transfers which made it
not perform the "TRB valid?" check after evaluating the Link TRB.
So, being implementation-defined behavior, I am guessing that
this same problem was also the cause of boot failures on real
hardware.
This also means that the problem was essentially a race condition,
as if we posted another transfer to the ring before it evaluated
the TRB, it would always work.
The solution of course is to put some valid TRB at the end of
every transfer on the Endpoint ring. A "no-op" would have done
the job (well, maybe not, it appears QEMU does not implement "no-op"
TRBs for some reason), but there was another feature of XHCI
that we did not take advantage of: Event Data TRBs. These provide
the "total transferred length" as well as the status, instead of
the "remaining length" of the final TRB.
This of course required refactoring the use of the CHAIN bit
and the IOC bit (namely, more or less all TRBs save the Event Data
get the CHAIN bit set, and none save Event Data get the IOC bit.)
There was also an update to the XHCI spec since I've last committed here,
so the new comments are in reference to the "XHCI 1.2" spec. (I'll
eventually find time to update the old ones.)
Fixes booting from USB3 on QEMU, and most likely also on
bare metal, where it at least got to usb_disk (it does
not seem to fix the case where usb_disk does not even start.) Whew!
Whenever using Terminal in fullscreen mode, there is a permanently on
tooltip with the shortcut to exit fullscreen mode wherever you leave
your mouse. This is super annoying and as a result I find myself rarely
using fullscreen mode.
Remove the tooltip, and instead add a button to the right of the tab bar
to exit fullscreen mode, as done in WonderBrush and WebPositive.
Change-Id: If42f038da3d644970de6214a31195882d4fc7eee
Reviewed-on: https://review.haiku-os.org/c/1507
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Remove a currently unused copy of it from HaikuDepot.
Change-Id: Idb97fae8e7190da6bc1049b3c1f1df929ea91bab
Reviewed-on: https://review.haiku-os.org/c/1506
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We always want to use the shared one from the syslibs package,
never the shared one from this build.
Part of #14842: after this change, the ICU build now fails with
"cannot find libstdc++" instead of an invalid symbol.
* If Volume::Mount() failed opening the root node, the Volume would be
destroyed regardless of the fact that the block allocator was
initializing the bitmap asynchronously.
* For a proper shutdown, the block allocator needs to be uninitialized
first.
* This should fix#15015.
Change-Id: Ice520a12c5c58c785f391009327becfb1f284bce
Reviewed-on: https://review.haiku-os.org/c/1501
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
It's quite annoying to install the new debug_server and test with a
crashing app everytime. So add a DebugWindow app that just shows the
debug window and returns the result.
Change-Id: I7238057a508871ce3fffc493cb73126eb852d99e
Reviewed-on: https://review.haiku-os.org/c/1460
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Use radio buttons laid out vertically so that locales with long labels
(no short word for "write core file") can still look nice. This is open
for experiment, buttons laid out vertically are another option. At least
now we have a window t work from, as BAlert doesn't cut it here.
While I'm at it, use a ladybug icon for this one, so it's visibly
different from normal application alerts.
Change-Id: I08ba9573f132901484224e107404348e7dca97f4
Reviewed-on: https://review.haiku-os.org/c/1459
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: I2343a6f2db2f95e33991e16c3a9cbd5445f90790
Reviewed-on: https://review.haiku-os.org/c/1499
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* After the gcc 8 upgrade, during bootstrap sources attempt to
load limits.h from gcc before they use our limits.h override
resulting in undefined NAME_MAX, PATH_MAX, etc.
Change-Id: I9204410d0543a033e262124eaf7bcde09db26aa9
Reviewed-on: https://review.haiku-os.org/c/1498
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
