On Fri, Dec 7, 2018 at 2:18 AM Borislav Petkov <[email protected]> wrote: > > On Thu, Dec 06, 2018 at 11:12:31AM -0800, [email protected] wrote: > > These are implied by the target architecture and for x86_64 match the > > max-page-size. The default for non-NaCl x86_64 is 0x1000 (4096). > > > > In bfd the common page size is defined as 0x1000 (4096) for non-NaCl > > Sodium Chloride?
Google's Native Client, a technology for running native code in a web browser. It's since been superseded by Portable Native Client (pNaCl) and to an extent Web Assembly. It seems that BFD still contains code for NaCl. > > > x86_64 targets: > > > > bfd/elf64-x86-64.c: > > 4998:#define ELF_COMMONPAGESIZE 0x1000 > > > > For gold, the common page size is defined as 0x1000 (4096) for non-NaCl > > x86_64 targets: > > > > gold/x86_64.cc: > > 1413: 0x1000, // common_pagesize (overridable by -z common-page-size) > > 1442: 0x1000, // common_pagesize (overridable by -z common-page-size) > > > > (ELF_COMMONPAGESIZE also defaults to ELF_MAXPAGESIZE when not set > > explicitly for a target architecture in bfd/elfxx-target.h, but that's > > not relevant for x86_64). > > > > Because it's implied by the target architecture, it's of questionable > > use to implement in LLD. This patch resolves one of the issues towards > > using LLD to link an x86_64 kernel. > > LLD? LLD is LLVM's linker. https://lld.llvm.org/ > > I can only guess what this commit message is about and have to look at > the patch itself and then look at the LD(1) man page and rhyme up what > it is aiming to do. > > How about rewriting it for mere mortals? How does this sound: TL;DR -z common-page-size's default value is based on the target architecture. arch/x86/entry/vdso/Makefile sets it to the architecture default, which is implicit and redundant. Drop it. -- Thanks, ~Nick Desaulniers
