OSDev.org

linuxyne wrote:

kzinti wrote: Yes, if it was a problem, the assembler or linker would complain.

Thanks for the clarification.

---

Is it possible for the s_sinks to lie outside of bss?

Below are the limits of the bss for a run:

Code: Select all

0xffffffff80126000 to 0xffffffff8012bb50

See below, which is very likely the Logger::initialize function comparing the s_sinks and s_write_lock resp.

One can see that it looks beyond the limits of bss for s_sinks - 0xffffffff8012bb58.

Code: Select all

ffffffff801179e2:	83 3d 6f 41 01 00 00 	cmpl   $0x0,0x1416f(%rip)        # 0xffffffff8012bb58
ffffffff801179e9:	48 89 e5             	mov    %rsp,%rbp
ffffffff801179ec:	41 56                	push   %r14
ffffffff801179ee:	41 55                	push   %r13
ffffffff801179f0:	41 54                	push   %r12
ffffffff801179f2:	53                   	push   %rbx
ffffffff801179f3:	0f 85 71 02 00 00    	jne    0xffffffff80117c6a
ffffffff801179f9:	48 83 3d 4f 41 01 00 	cmpq   $0x0,0x1414f(%rip)        # 0xffffffff8012bb50
ffffffff80117a00:	00 
ffffffff80117a01:	0f 85 44 02 00 00    	jne    0xffffffff80117c4b

The disassembly was generated by running the following on Kernel.bin. That is, the start of the Kernel.bin is at 0xffffffff80100000.

Code: Select all

objdump -b binary -D -m i386:x86-64 --adjust-vma=0xffffffff80100000

Edit:

Heh.

Code: Select all

0000000000000000 l    d  .bss._ZN6kernel6Logger7s_sinksE	0000000000000000 .bss._ZN6kernel6Logger7s_sinksE
0000000000000000  w    O .bss._ZN6kernel6Logger7s_sinksE	0000000000000008 _ZN6kernel6Logger7s_sinksE

You might want to try adding *(.bss.*) and/or *(.bss*), whichever is more general and allowed, to the linker script.

8infy wrote: OMG! That was it! the section literally moved 16 bytes down and that was enough.... Thank you so much man
Now it boots successfully on that laptop

8infy wrote: (You can submit a pull request if you want to get "official" credit for it, its you who found the problem after all)