Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linker script error (nano_core binary linkage) #604

Open
NathanRoyer opened this issue Aug 16, 2022 · 4 comments
Open

Linker script error (nano_core binary linkage) #604

NathanRoyer opened this issue Aug 16, 2022 · 4 comments

Comments

@NathanRoyer
Copy link
Member

My GNU ld (GNU Binutils) 2.39 complains about our linker script when building Theseus:

ld: warning: build/nano_core/asm_common_x86_64.o: missing .note.GNU-stack section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
ld: warning: build/nano_core/nano_core-x86_64.bin has a LOAD segment with RWX permissions

It appears some sections are either missing or incorrect.

@kevinaboos
Copy link
Member

Looks like we can just add a .no.GNU-stack marker section to indicate to the linker that our stack isn't executable. Does that fix the issue on your end?

Also, did you perhaps change some other part of the build procedure? I only ask because typically there isn't a file called asm_common_x86_64.o, it's just called common.o on my build, which is built from kernel/nano_core/src/boot/arch_x86_64/common.asm.

@kevinaboos
Copy link
Member

Actually the changelog from binutils v2.39 implies that we may need to add a .note.GNU-stack section to every input file (so, all of the assembly files).

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=ld/NEWS;hb=refs/heads/binutils-2_39-branch

If you try that does it resolve the error?

@NathanRoyer
Copy link
Member Author

I appended an empty section with that name to all asm files except defines.asm and the first warning disappeared; the second one remain.

@kevinaboos
Copy link
Member

kevinaboos commented Aug 29, 2022

ok great!

For the other issue, i found this email thread that seems to indicate it might be an issue with the max page size.

If you look at the output of readelf -lSW on the kernel.bin file you'll see that almost all of the sections are being combined into one loadable segment:

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  LOAD           0x000120 0x0000000000100000 0x0000000000100000 0x000526 0x000526 R E 0x8
  LOAD           0x001000 0xffffffff80101000 0x0000000000101000 0x191500 0x199000 RWE 0x1000
  LOAD           0x000000 0xffffffff80600000 0x0000000000600000 0x000000 0x012000 RW  0x1000
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x10

 Section to Segment mapping:
  Segment Sections...
   00     .init 
   01     .text .rodata .eh_frame .gcc_except_table .data .bss .page_table 
   02     .stack 
   03     

I think that's the source of the issue. If we set max page size to 4K then it probably won't force the non-4K-aligned sections to be in the same segment.

Let me know if that works for you. I don't want to align everything to 2MiB page boundaries so its best to just tell ld that explicitly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants