Why MergeObjectFromObjects1 rule is needed?

Did you mean this?

error mapping file data: Invalid Argument!
error starting "/boot/system/servers/launch_daemon" error = -1 

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.

Possibly related https://dev.haiku-os.org/ticket/10198#comment:8

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!
Haiku%20(clang)

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:

  1. Linking of boot_loader_bios_ia32 fails because __divdi3, __moddi3, __udivdi3, __umoddi3 symbols are not found.
  2. Cleanup of Jam files is required:
    2.1 Clang need --no-rosegment -znorelro flags 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.
  3. Hybrid 32 bit builds need to be checked.
  4. Invalid MBR is generated and some tools fails to compile because MBR size is wrong.
  5. 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.