Did you mean this?
error mapping file data: Invalid Argument!
error starting "/boot/system/servers/launch_daemon" error = -1
Why MergeObjectFromObjects1 rule is needed?
2 RW LOAD entries in program header table may be an issue.
No, I mean it completely seg-faulted and userland did not start at all. But perhaps that we due to some other problem which has since been resolved.
It seems that ELF loader of haiku_loader don’t support multiple LOAD segments with same type: https://git.haiku-os.org/haiku/tree/src/system/boot/loader/elf.cpp#n204. I can’t find lld option to disable multiple LOAD segments of same type, so ELF loader need to adjusted to support multiple LOAD segments of same type.
“attempted static link of dynamic object” error was caused by using HAIKU_LD_x86_64=clang at first attempts of compiling. After changing it to HAIKU_LD_x86_64=ld.lld, haiku.hpkg is compiled fine with clang/lld without GNU ld at all.
1 Like
I found lld flags that produce same segment layout as GNU ld: -Wl,--no-rosegment -Wl,-znorelro.
I used --no-rosegment -znorelro flags to kernel, kernel add-ons and runtime_loader and now kernel and kernel add-ons built with clang/lld successfully load and run, but runtime_loader still fail:
vm_soft_fault: va 0x7fe8400c2000 not covered by area in address space
vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x7fe8400c2ff8, ip 0x3dd5ed56b4, write 1, user 1, thread 0x11a
thread_hit_serious_debug_event(): Failed to install debugger: thread: 282: Bad port ID
error starting "/boot/system/servers/launch_daemon" error = -1
1 Like
I tried to add panic call to vm_page_fault and get following output:
vm_soft_fault: va 0x7f8214849000 not covered by area in address space
vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x7f8214849ff8, ip 0xbc843ec6b4, write 1, user 1, thread 0x11a
PANIC: vm_page_fault: page fault in user space at 0x7f8214849ff8, ip 0xbc843ec6b4
Welcome to Kernel Debugging Land...
Thread 282 "launch_daemon" running on CPU 0
stack trace for thread 282 "launch_daemon"
kernel stack: 0xffffffff820ed000 to 0xffffffff820f2000
user stack: 0x00007f821484a000 to 0x00007f821584a000
frame caller <image>:function + offset
0 ffffffff820f1a38 (+ 24) ffffffff8014709c <kernel_x86_64> arch_debug_call_with_fault_handler + 0x16
1 ffffffff820f1a50 (+ 176) ffffffff800b2c9c <kernel_x86_64> kernel_debugger_internal(char const*, char const*, __va_list_tag*, int) + 0x38c
2 ffffffff820f1b00 (+ 240) ffffffff800b3927 <kernel_x86_64> panic + 0xb7
3 ffffffff820f1bf0 (+ 240) ffffffff8012d797 <kernel_x86_64> vm_page_fault + 0x117
4 ffffffff820f1ce0 (+ 64) ffffffff80151ccb <kernel_x86_64> x86_page_fault_exception + 0x23b
5 ffffffff820f1d20 (+ 536) ffffffff80148a1d <kernel_x86_64> int_bottom_user + 0xb2
user iframe at 0xffffffff820f1f38 (end = 0xffffffff820f2000)
rax 0x7290410b60 rbx 0x7290410b60 rcx 0x0
rdx 0x4 rsi 0x0 rdi 0x7290410b60
rbp 0x7f821484a000 r8 0x7f8215848d70 r9 0x7f8215848d70
r10 0x6480 r11 0x7ff8 r12 0x729040ae98
r13 0x13 r14 0x7290407008 r15 0x3
rip 0xbc843ec6b4 rsp 0x7f821484a000 rflags 0x13202
vector: 0xe, error code: 0x6
6 ffffffff820f1f38 (+140198779650248) 000000bc843ec6b4 </boot/system/runtime_loader@0x000000bc843cf000> <unknown> + 0x1d6b4
7 00007f821484a000 (+ 32) 000000bc843ec787 </boot/system/runtime_loader@0x000000bc843cf000> <unknown> + 0x1d787
8 00007f821484a020 (+ 32) 000000bc843ec787 </boot/system/runtime_loader@0x000000bc843cf000> <unknown> + 0x1d787
9 00007f821484a040 (+ 32) 000000bc843ec787 </boot/system/runtime_loader@0x000000bc843cf000> <unknown> + 0x1d787
10 00007f821484a060 (+ 32) 000000bc843ec787 </boot/system/runtime_loader@0x000000bc843cf000> <unknown> + 0x1d787
11 00007f821484a080 (+ 32) 000000bc843ec787 </boot/system/runtime_loader@0x000000bc843cf000> <unknown> + 0x1d787
12 00007f821484a0a0 (+ 32) 000000bc843ec787 </boot/system/runtime_loader@0x000000bc843cf000> <unknown> + 0x1d787
13 00007f821484a0c0 (+ 32) 000000bc843ec787 </boot/system/runtime_loader@0x000000bc843cf000> <unknown> + 0x1d787
14 00007f821484a0e0 (+ 32) 000000bc843ec787 </boot/system/runtime_loader@0x000000bc843cf000> <unknown> + 0x1d787
15 00007f821484a100 (+ 32) 000000bc843ec787 </boot/system/runtime_loader@0x000000bc843cf000> <unknown> + 0x1d787
16 00007f821484a120 (+ 32) 000000bc843ec787 </boot/system/runtime_loader@0x000000bc843cf000> <unknown> + 0x1d787
17 00007f821484a140 (+ 32) 000000bc843ec787 </boot/system/runtime_loader@0x000000bc843cf000> <unknown> + 0x1d787
18 00007f821484a160 (+ 32) 000000bc843ec787 </boot/system/runtime_loader@0x000000bc843cf000> <unknown> + 0x1d787
19 00007f821484a180 (+ 32) 000000bc843ec787 </boot/system/runtime_loader@0x000000bc843cf000> <unknown> + 0x1d787
20 00007f821484a1a0 (+ 32) 000000bc843ec787 </boot/system/runtime_loader@0x000000bc843cf000> <unknown> + 0x1d787
Ending part infinitely repeats.
Yep, this is identical behavior to what I saw when I built Haiku with Clang + binutils ld. I didn’t manage to debut the “infinite repeat” any further.
I replaced runtime_loader and libroot.so (clang version of libroot.so currently cause problem with infinite output similar to runtime_loader) from GCC build and now it is working!
3 Likes
libroot.so issue is reproduceable on regular Haiku build by putting it it lib folder:
thread 50177: w>StyledEdit: Open
state: Exception (Segment violation)
Frame IP Function Name
-----------------------------------------------
0x7ff500d1f000 0x375bea4b94 /boot/home/Desktop/New folder/lib/libroot.so + 0xf6b94
Unable to retrieve disassembly for IP 0x375bea4b94: address does not point to a function.
0x7ff500d1f020 0x375bea4c67 /boot/home/Desktop/New folder/lib/libroot.so + 0xf6c67
0x7ff500d1f040 0x375bea4c67 /boot/home/Desktop/New folder/lib/libroot.so + 0xf6c67
0x7ff500d1f060 0x375bea4c67 /boot/home/Desktop/New folder/lib/libroot.so + 0xf6c67
0x7ff500d1f080 0x375bea4c67 /boot/home/Desktop/New folder/lib/libroot.so + 0xf6c67
0x7ff500d1f0a0 0x375bea4c67 /boot/home/Desktop/New folder/lib/libroot.so + 0xf6c67
0x7ff500d1f0c0 0x375bea4c67 /boot/home/Desktop/New folder/lib/libroot.so + 0xf6c67
...
0x7ff500d5dc20 0x375bea4c67 /boot/home/Desktop/New folder/lib/libroot.so + 0xf6c67
0x7ff500d5dc40 0x375bea4c67 /boot/home/Desktop/New folder/lib/libroot.so + 0xf6c67
0x7ff500d5dc60 0x375bea4c67 /boot/home/Desktop/New folder/lib/libroot.so + 0xf6c67
0x7ff500d5dce0 0x20f8463de0a agg::rasterizer_compound_aa<agg::rasterizer_sl_clip<agg::ras_conv_dbl> >::sweep_styles() + 0x18a
0x7ff500d5ddd0 0x20f8463e964 void agg::render_scanlines_compound<agg::rasterizer_compound_aa<agg::rasterizer_sl_clip<agg::ras_conv_dbl> >, agg::scanline_u8, agg::scanline_bin, agg::renderer_base<agg::pixfmt_alpha_blend_rgba<agg::blender_rgba_pre<agg::rgba8, agg::order_bgra>, agg::row_ptr_cache<unsigned char>, unsigned int> >, agg::span_allocator<agg::rgba8>, BPrivate::Icon::IconRenderer::StyleHandler>(agg::rasterizer_compound_aa<agg::rasterizer_sl_clip<agg::ras_conv_dbl> >&, agg::scanline_u8&, agg::scanline_bin&, agg::renderer_base<ag
0x7ff500d5ddf0 0x20f8463b3b3 BPrivate::Icon::IconRenderer::_CommitRenderPass(BPrivate::Icon::IconRenderer::StyleHandler&, bool) + 0x33
0x7ff500d5def0 0x20f8463bbed BPrivate::Icon::IconRenderer::_Render(BRect const&) + 0x78d
0x7ff500d5df20 0x20f8463c0a4 BPrivate::Icon::IconRenderer::Render() + 0x24
0x7ff500d5e280 0x20f8462fc60 BIconUtils::GetVectorIcon(unsigned char const*, unsigned long, BBitmap*) + 0x1c0
0x7ff500d5e2d0 0x20f84630006 BIconUtils::GetVectorIcon(BNode*, char const*, BBitmap*) + 0xf6
0x7ff500d5e3a0 0x20f846301c0 BIconUtils::GetIcon(BNode*, char const*, char const*, char const*, icon_size, BBitmap*) + 0x180
0x7ff500d5e460 0x20f8462cb3b BPrivate::Storage::Mime::DatabaseLocation::GetIconForType(char const*, char const*, BBitmap&, icon_size) + 0x16b
0x7ff500d5e540 0xd8f3f37fbc BPrivate::IconMenuItem::IconMenuItem(BMenu*, BMessage*, char const*, icon_size) + 0xbc
0x7ff500d5e7a0 0xd8f3f01753 BPrivate::BContainerWindow::AddMimeMenu(BMimeType const&, bool, BMenu*, int) + 0x3e3
0x7ff500d5e8e0 0xd8f3f01a2a BPrivate::BContainerWindow::AddMimeTypesToMenu(BMenu*) + 0x1aa
0x7ff500d5e920 0xd8f3f533a6 BPrivate::BPoseView::AddPosesCompleted() + 0x36
0x7ff500d5e940 0xd8f3f1dd8c BPrivate::BFilePanelPoseView::AddPosesCompleted() + 0xc
0x7ff500d5ea50 0xd8f3f65676 BPrivate::BPoseView::MessageReceived(BMessage*) + 0x9e6
0x7ff500d5ec80 0x20f845c260e BWindow::DispatchMessage(BMessage*, BHandler*) + 0xb3e
0x7ff500d5eca0 0xd8f3f1c3ad BPrivate::TFilePanel::DispatchMessage(BMessage*, BHandler*) + 0xd
0x7ff500d5ed30 0x20f845bdc5b BWindow::task_looper() + 0x1bb
0x7ff500d5ed50 0x20f84503f2b BLooper::_task0_(void*) + 0x1b
0x7ff500d5ed80 0x375be24f99 __wcstof_internal + 0x1f09
00000000 0x7fcc4b325260 commpage_thread_exit + 0
Registers:
rip: 0x000000375bea4b94
rsp: 0x00007ff500d1f000
rbp: 0x00007ff500d1f000
rax: 0x0000001e3113c240
rbx: 0x0000001e3113c240
rcx: 0x0000000000000004
rdx: 0x0000000000000001
rsi: 0x0000000000000000
rdi: 0x0000001e3113c240
r8: 0x0000000000000000
r9: 0x0000000000000006
r10: 0x00007ff500d5da10
r11: 0x0000001e31153c18
r12: 0x0000000000000001
r13: 0x8000000100000000
r14: 0x0000000000000004
r15: 0x00007ff500d5e0b0
cs: 0x002b
ds: 0x0000
es: 0x0000
fs: 0x0000
gs: 0x0000
ss: 0x0023
st0: nan
st1: nan
st2: 0
st3: 0
st4: 0
st5: 0
st6: 0
st7: nan
mm0: {0, 0, 0, 0}
mm1: {0x100, 0, 0, 0}
mm2: {0, 0, 0, 0}
mm3: {0, 0, 0, 0}
mm4: {0, 0, 0, 0}
mm5: {0, 0, 0, 0}
mm6: {0, 0, 0, 0}
mm7: {0xf83a, 0xffff, 0, 0}
xmm0: {0, 0, 0, 0, 0, 0, 0, 0}
xmm1: {0, 0x6000, 0xdf5f, 0x401e, 0, 0, 0, 0}
xmm2: {0, 0, 0, 0, 0, 0, 0, 0}
xmm3: {0, 0, 0, 0, 0, 0, 0, 0}
xmm4: {0, 0, 0, 0x3fe0, 0, 0, 0, 0}
xmm5: {0, 0x6000, 0xe15f, 0x409e, 0, 0, 0, 0}
xmm6: {0x6, 0, 0x2, 0, 0x12, 0, 0xa600, 0xffff}
xmm7: {0x1, 0, 0x7, 0, 0x67, 0, 0x2d10, 0}
xmm8: {0, 0, 0, 0, 0, 0, 0, 0}
xmm9: {0, 0xc000, 0xbebe, 0x4022, 0, 0, 0, 0}
xmm10: {0, 0, 0, 0, 0, 0, 0, 0}
xmm11: {0, 0xc000, 0xbebe, 0x4022, 0, 0, 0, 0}
xmm12: {0, 0, 0, 0x403a, 0, 0, 0, 0}
xmm13: {0, 0, 0, 0x403a, 0, 0, 0, 0}
xmm14: {0, 0, 0xf0f1, 0x4004, 0, 0, 0, 0}
xmm15: {0, 0x6000, 0xdf5f, 0x403e, 0, 0, 0, 0}
libroot.so + 0xf6c67 is inside memset function and is return address after _memset external funstion. Seems that _memset is dynamically linked with something wrong and call itself.
Problem in runtime_loader is the same. </boot/system/runtime_loader@0x000000bc843cf000> <unknown> + 0x1d787 is also return address of _memset. Problem is likely that clang produce memset call inside memset implementation causing stack overflow.
I commented some code in memset implementation to avoid infinite recursion and now pure clang/lld Haiku build is working fine:
extern "C" void*
memset(void* ptr, int chr, size_t length)
{
auto value = static_cast<unsigned char>(chr);
auto destination = static_cast<uint8_t*>(ptr);
/*
if (length < 32) {
memset_small(destination, value, length);
return ptr;
}
if (length < 2048) {
memset_sse(destination, value, length);
return ptr;
}
*/
memset_repstos(destination, value, length);
return ptr;
}
Trac ticket: #15827.
2 Likes
Remaining problems with Haiku clang build:
- Linking of
boot_loader_bios_ia32fails because__divdi3,__moddi3,__udivdi3,__umoddi3symbols are not found. - Cleanup of Jam files is required:
2.1 Clang need--no-rosegment -znorelroflags for kernel, kernel add-ons and runtime_loader.
2.2 clang headers should be used insted of GCC.
2.3 Some clang-specific warnings need to be silenced.
2.4 Many old clang-specific handling should be removed because it is obsolete. - Hybrid 32 bit builds need to be checked.
- Invalid MBR is generated and some tools fails to compile because MBR size is wrong.
- atexit is used in kernel and kernel add-ons instead of __cxa_atexit. Probably some Haiku target settings in clang are wrong.
1 Like
You need a 32-bit libgcc, which comes with the x86_64 cross compiler but of course is not available when GCC is not used. I’ve hacked one into my Jamfiles before and made this work.
Is there a good reason we should not just fix the kernel here?
Such as…? I’ve already moved most Clang-specific stuff that was not needed.
./configure already does this?
Yes. This used to work, LLVM changed something around version 7 or so and now it doesn’t, and I never looked into it.
No, this flags are not needed if #15819 and #15820 will be fixed. lld use different segment layout for better security.
I didn’t checked exactly yet, I currently build Haiku with clang without clang handling and with some patches. Clang handling don’t work for me.
1 Like
Following build method is working fine:
clang -c -m32 mbr.S
llvm-objcopy -O binary mbr.o mbr.bin
Also work with gcc and objcopy.
Returning to start post question, lld PE/COFF linker seems don’t support -r option. I tried to build PE module for haiku_loader.efi with clang/lld and MergeObjectFromObjects1 rule fails. Note that when linking PE executable, object files need to be in COFF format, ELF is not supported.