<waddlesplash>
zdykstra: this is with failsafe graphics enabled?
<waddlesplash>
that's weird, it shouldn't try to do that. but I might recall having seen tickets about this before somewhere
<zdykstra>
That's with failsafe enabled and smp disabled
<waddlesplash>
well, clearly a bug of some kind
<waddlesplash>
check and see if it's reported, if not it definitely deserves a ticket
<zdykstra>
4 screens attached, so that might be confusing it?
<waddlesplash>
can you invoke KDL via the keyboard shortcut here?
<x512[m]>
Vesa with recent changes is no longer "fail safe".
<waddlesplash>
x512[m]: I'm guessing zdykstra is booting via efi
<zdykstra>
I am, yes
<waddlesplash>
and yeah we probably need to add handling to the vesa driver to not do patching
<x512[m]>
Real fail safe is not touching video mode set by boot loader.
<waddlesplash>
zdykstra: the framebuffer driver doesn't do anything but use the fb set up by the bootloader
<waddlesplash>
so it shouldn't be confused by anything
<waddlesplash>
somehow appserver has gotten confused and is trying to set modes which it shouldn't be doing
<x512[m]>
app_server tries to set mode anyway and something goes wrong?
<waddlesplash>
apparently
thomaslewis has joined #haiku
<zdykstra>
What's the keyboard shortcut for kdl?
<waddlesplash>
zdykstra: anyway if you can drop to KDL you should be able to get a backtrace of appserver which should tell us what might be going wrong
<waddlesplash>
Alt+SysRq+D
<zdykstra>
Can't seem to get to KDL, hmm
thomaslewis has left #haiku [#haiku]
<zdykstra>
Anything else I can try before I reboot?
x10z has joined #haiku
<x512[m]>
Stupid question: how to convert (begin, length) pair to (begin, end) considering that overflow can happen?
<waddlesplash>
you mean, you want the overflow?
<waddlesplash>
and you just want begin < end?
<x512[m]>
I want to check that one range is fully inside another range. Ranges are defined with (begin, lengrh) pair.
<zdykstra>
okay, can't get to KDL - but failsafe graphics on/off changes nothing, nor does selecting a resolution in the bootloader. It changes the boot screen, but it still blocks on the rocketship.
<waddlesplash>
weird
<waddlesplash>
not that surprising you can't get to KDL, I've never had much success trying to get to it before the desktop appears
<zdykstra>
would changing from this amdgpu to an older nvidia of some flavor possibly help?
<waddlesplash>
no
<waddlesplash>
because either way we should be using the fallback graphics driver and app server shouldn't be trying to change modes
<zdykstra>
is ther a ticket that I can bump with information, or would you prefer I create a new one?
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<trungnt2910[m]>
Which part of Haiku is responsible for initializing Haiku TLS?
<trungnt2910[m]>
The kernel? runtime_loader? libroot?
<trungnt2910[m]>
Currently my modified `runtime_loader` on Linux is running smoothly: It loads an executable, libgcc_s, and then libroot... until it trips on a function that accesses the TLS.
<x512[m]>
x86_64?
<trungnt2910[m]>
Haiku x86_64 `runtime_loader` running on Linux.
<waddlesplash>
trungnt2910[m]: there's simply no way you're going to get most of this to work
<waddlesplash>
you should start with libroot_build
<waddlesplash>
you will simply have to use a linux-based C library, you can't just use raw syscalls
<waddlesplash>
because linux syscalls don't actually mirror what the C library needs them to do, most of the time
<trungnt2910[m]>
Well I'm using Haiku binaries but I removed the `syscalls.o` object.
<waddlesplash>
yes, that's never going to work
<x512[m]>
Haiku use FS segment for TLS on x86_64.
<trungnt2910[m]>
And then I implemented everything in terms of Linux syscalls, and re-link the binaries on Linux.
<waddlesplash>
everything?
<waddlesplash>
already?
<trungnt2910[m]>
waddlesplash: No, 90% are just stubs.
<waddlesplash>
again, not going to work because lots of linux syscalls do not have any kind of easy correspondence
<waddlesplash>
with the C functions they are needed to implement
<waddlesplash>
IIRC the thread-related syscalls are especially strange, or at least they used to be, and stuff like setpid() also doesn't behave right
<nekobot>
[haiku/haiku] fb1d7157d221 - ps2: do not publish keyboard device until mouse probing is complete
<trungnt2910[m]>
<waddlesplash> "reimplementing a "C library..." <- What's a "C library" interface? And what does reimplementing Haiku syscalls got to do with that?
<waddlesplash>
you know, the standard C library: read/write, FILE* functions, memory functions, ...
<waddlesplash>
setpid, chown, realpath, traversal, etc.
<waddlesplash>
Haiku's implementations of these functions expect highly specific syscall behavior
<waddlesplash>
and more to the point, some of them expect things that Linux just doesn't readily support
<trungnt2910[m]>
Even more specific than Windows and MacOS?
<waddlesplash>
for instance, open()ing files by inode, which you can only do on Linux as root
<waddlesplash>
and even then I think it requires some special handling per-filesystem or something
<trungnt2910[m]>
waddlesplash: My goal is not the full Haiku userland, just enough for a C compiler.
<waddlesplash>
so ... use the cross compiler??
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
<waddlesplash>
jessicah has scripts somewhere that turn the crosstools compiler into a more standard one
<waddlesplash>
it's of course fully linux-native, it has to be to build Haiku itself
<waddlesplash>
so, just use that?
<x512[m]>
waddlesplash: Running Haiku compiler binaries allow to run HaikuPorter.
<trungnt2910[m]>
trungnt2910[m]: And test console POSIX Haiku applications.
<waddlesplash>
x512[m]: haikuporter recipes basically depend on being natively built
<waddlesplash>
even if you work around packagefs somehow you are going to run into weird problems related to extended attributes
<waddlesplash>
this is just not a good idea
<x512[m]>
So if all dependencies used by HaikuPorter wiil be able to run on Linux, some Linux server can be used for CI.
<waddlesplash>
in fact it might be legitimately easier to create some kind of "hosted" mode for the Haiku kernel, so it can run on top of other kernels or itself, than this
<x512[m]>
waddlesplash: What is a problem with attributes? Linux supports xattr.
<trungnt2910[m]>
How's that different?
<waddlesplash>
trungnt2910[m]: it means running the full Haiku kernel as a kind of "application"
<waddlesplash>
there's a way to do this to run the Linux kernel on top of itself
<waddlesplash>
and I think FreeBSD may have a similar mode?
<x512[m]>
waddlesplash: It will be slow?
<waddlesplash>
x512[m]: not typed ones.
<waddlesplash>
x512[m]: it'll be much faster than using a VM
<waddlesplash>
which I think is the point in the first place
<zdykstra>
I highly doubt any CI system would support that, unless you can run it as a userland binary
<trungnt2910[m]>
waddlesplash: Slower than stuff such as Wine?
<waddlesplash>
I don't know, how slow is WINE and why is it slow?
<waddlesplash>
most people don't run compilers on WINE but GUI applications and judge it by this
<trungnt2910[m]>
I thought WINE is fast?
<waddlesplash>
I would bet compilers on WINE can be faster than they are on native Windows
<x512[m]>
Because Haiku have no epoll or equivalents?
<waddlesplash>
x512[m]: no, I mean on Linux
<waddlesplash>
trungnt2910[m]: yes, and WINE doesn't invoke Linux syscalls directly
<trungnt2910[m]>
waddlesplash: I mean would this solution be slower than stuff such as WINE?
<waddlesplash>
it links to the C library
<x512[m]>
Wine wait for more then 100 fds even for simple applications.
<waddlesplash>
oh. probably, but I don't know by how much
<waddlesplash>
x512[m]: yeah, I need to work on the event queue system
<x512[m]>
wine_server is very Linuxish.
<x512[m]>
And single threaded.
<x512[m]>
On Haiku designed servers it is usually not a problem because servers are multi-threaded and message based.
<x512[m]>
Linux designed software tends to design one process global main loop that wait on fd list.
<trungnt2910[m]>
<waddlesplash> "trungnt2910: it means running..." <- But well, I don't even know how that works in the first place.
<trungnt2910[m]>
On the other hand, I already have experience working with MacOS to Linux syscall translation stuff so I'm just a bit more confident.
<trungnt2910[m]>
<waddlesplash> "this is just not a good idea" <- It's not a serious project in the first place, just a way for me to kill time while waiting pull requests to get reviewed and merged.
<x512[m]>
Haiku currently still use obsolete eh_frame registration method. Most other ELF systems use eh_frame_hdr. LLVM libunwind do not support eh_frame registration method used in Haiku.
<waddlesplash>
x512[m]: we just enabled eh_frame generation in haiku gcc
<waddlesplash>
a few days ago
<x512[m]>
Linuxes did it 10+ years ago.
<waddlesplash>
yes, I know, but we're catching up :)
<x512[m]>
Are GCC used for HaikuPorts building udpated?
<waddlesplash>
x512[m]: because this is the version all other *NIXes appear to actually use in production, especially with .NET which seems to incorporate it into its own source tree.
<waddlesplash>
meanwhile the LLVM one was contributed by Apple and isn't anywhere near as widely used
<waddlesplash>
in fact the .NET/Mono system seems to have a custom version of this libunwind, maybe with custom features, that pulls from this one only.
<x512[m]>
LLVM libunwind expose that other libunwind API.
<waddlesplash>
only "most of it"
<x512[m]>
With eh_frame_hdr support, PDE lookup can be done in stateless way so multiple unwind libraries can be used in the same process without conflicts.
<x512[m]>
> Files changed 27
<waddlesplash>
a bunch of that can now be removed since we have a real dl_iterate_phdr
<x512[m]>
Looks much more difficult to port compared to LLVM libunwind.
<trungnt2910[m]>
waddlesplash: She claimed not to know what she's doing (in a direct message with me)
<trungnt2910[m]>
And that hasn't been tested yet.
<waddlesplash>
trungnt2910[m]: yeah, but a lot of the patch can now be removed now that we have a dl_iterate_phdr
<waddlesplash>
that commit is one of their changes to add custom features or behavior on top of the existing libunwind ones.
<waddlesplash>
they routinely merge changes from libunwind upstream but they have their own patches too
<waddlesplash>
I don't think they really support running on any libunwind but that one.
<waddlesplash>
trungnt2910[m]: I bet now that we have eh_frame and dl_iterate_phdr we can build that libunwind with a modified version of jessicah's patch and it will work
<x512[m]>
So non-LLVM libunwind is broken at least for ARM and .NET project privately fixed it? Looks like a mess.
<waddlesplash>
x512[m]: "This change updates the libunwind so that both exidx and dwarf ways of unwinding can unwind"
<trungnt2910[m]>
waddlesplash: No, I mean for .NET
<waddlesplash>
trungnt2910[m]: where do you see that?
<trungnt2910[m]>
Sorry for the late reply, was in a ranked match.
<trungnt2910[m]>
According to a member of the .NET foundation.
<trungnt2910[m]>
> Sounds good. I cannot think of anything wrong with the setup you have described. (We use LLVM libunwind on macOS and FreeBSD. It works fine. AFAIK, the only difference unw_get_save_loc (available in HP libunwind, but not LLVM libunwind) makes is that GC pins the objects longer in the absence of unw_get_save_loc, with save loc mechanism (which is based on ucontext) GC has granular control and can do a bit better job for objects'
<x512[m]>
Then no need to bother with non-LLVM libunwind. Having forked libunwind inside .NET repo is also a bad idea.
<waddlesplash>
ok
<x512[m]>
LLVM libunwind if already proofed to be functional on Haiku and it can be modified to run legacy eh_frame registration method.
<waddlesplash>
trungnt2910[m]: replied to your haikuports PR.
<x512[m]>
> In my case, it was ultimately the issue with signal handling (src/coreclr/pal/src/exception/signal.cpp and src/coreclr/pal/src/arch/amd64/callsignalhandlerwrapper.S).
<x512[m]>
.NET need proper stack unwind from signal frame?
<x512[m]>
I need to find solution to avoid using magic numbers for stack and code offsets.
<trungnt2910[m]>
x512[m]: That issue didn't happen on Haiku.
<trungnt2910[m]>
In the end, it was a bug from the cross-compiler not calling __register_frame_info properly.
<trungnt2910[m]>
(That's also one of the reason why I hate the Haiku cross-compiler).
<x512[m]>
I remember that Haiku cross compiler produced RISC-V executables with broken exception handling.
<trungnt2910[m]>
x512[m]: Same for x86_64
<x512[m]>
The only method to fix it was rebuilding GCC on RISC-V real hardware with regular HaikuPorts recipe.
<waddlesplash>
that sounds like something we should fix...?
<x512[m]>
Virtual machine is also possible but slow.
<waddlesplash>
or we should just change libgcc to also use eh_frame iteration...
<x512[m]>
Maybe GCC crosscompiler build recipe/script is broken.
<x512[m]>
I do not understand autotools at all so I have no idea at all.
nephele has joined #haiku
<x512[m]>
To me Autotools is something similar to mystery of building Egyptian pyramids. Some ancient forgotten technology.
<waddlesplash>
LOL
<trungnt2910[m]>
waddlesplash: And then you really HAVE to send all those old binaries to the void.
<nephele>
x512: I hope nobody was burried with autotools
<waddlesplash>
trungnt2910[m]: yeah, well, unfortunately we can't do that, so we'd have to support both mechanisms in libgcc
<x512[m]>
Or use my stub libgcc_s.
<x512[m]>
That is just to silence dynamic linker.
<trungnt2910[m]>
x512[m]: Which introduces backwards compatibility problems.
<nephele>
Hi waddlesplash
<nephele>
I dug out a PS/2 keyboard for you
<trungnt2910[m]>
Binaries compiled on libroot with your unwind patches can't run on normal Haiku.
<x512[m]>
trungnt2910[m]: What problems exactly?
<trungnt2910[m]>
trungnt2910[m]: this.
<trungnt2910[m]>
But it's fine the other way round.
<x512[m]>
Forward compatibility is not guaranteed.
<x512[m]>
Only backward.
<x512[m]>
Some another libgcc_s stub can be prepared just for linking. It can export all libgcc_s symbols, but with empty contents (abort() etc.).
<nekobot>
[haiku/haiku] 764c0853e8c6 - kernel/arm/thread: convert TRACE to new syntax
bbjimmy has joined #haiku
christech has joined #haiku
gouchi has joined #haiku
<zdykstra>
hey neat, re-enabling the trackpad in my thinkpads BIOS fixed the trackpoint buttons being disabled
<nephele>
heh
<zdykstra>
okay, am I crazy? I can click things with the mouse buttons below the trackpoint, but I can't drag anything with the trackpoint. I can only click-and-drag on the touchpad.
<zdykstra>
If I click and hold the mouse button, the trackpoint doesn't move anything.
<zdykstra>
I can click-and-drag to resize a window, though.
<zdykstra>
and I can click-and-drag to select multiple items on the desktop; but I can't actually move them with the trackpoint + buttons. Only the touchpad.
matt__ has joined #haiku
<waddlesplash>
I think I saw the same behavior myself on a ThinkPad once
<waddlesplash>
it's indeed strange. I didn't spend any time investigating
<extrowerk>
zdykstra: i see the same on my thinkpad
<zdykstra>
Until recently, I've only booted Haiku on my x200s, which only has a trackpoint. Booted it on my x260 and thought I was going crazy not being able to move icons on the desktop.
jmairboeck has quit [Quit: Konversation terminated!]
frkzoid has quit [Ping timeout: 480 seconds]
Anarchos has joined #haiku
<waddlesplash>
extrowerk: would you care to try working on a recipe for FontForge? don't use Xlibe directly; it has a GTK backend now
<extrowerk>
waddlesplash: i will look into it.
<extrowerk>
btw: i just replaced coreutils with sbase on Haiku.
<extrowerk>
It still boots.
<waddlesplash>
theoretically it should boot even without coreutils at all
<waddlesplash>
however the haiku package does depend on them
<extrowerk>
i did a pkgman remove coreutils, it brings the half world with
<waddlesplash>
yes, sbase could probably declare that it provides "coreutils"
<waddlesplash>
this way you could really replace coreutils
<waddlesplash>
that however may provide unexpected results so I wouldn't do it in the final package maybe
<extrowerk>
i just installed sbase and manually removed coreutils and did a reboot.
<extrowerk>
now sbase is activated and no dependant package got removed.
<extrowerk>
waddlesplash: i think i can attempt to write a recipe for it, but not for free.
<zdykstra>
time to figure out how to cancel my recurring PayPal donation
Gaspare has quit [Quit: Gaspare]
AlaskanEmily has joined #haiku
B2IA has joined #haiku
dpirate_ has quit [charon.oftc.net dacia.oftc.net]
x10z has joined #haiku
dpirate has joined #haiku
<zdykstra>
Diver: my Lenovo P620 only has UEFI mode, and I can't find any CSM compatibility toggles. So - I can only ever boot with an EFI framebuffer.
dpirate has quit [charon.oftc.net dacia.oftc.net]
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]