Page MenuHomeFreeBSD

ld.lld.1: document the rest of the -z options
AbandonedPublic

Authored by emaste on Feb 6 2018, 4:12 AM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 21 2024, 5:23 AM
Unknown Object (File)
Jan 29 2024, 2:23 PM
Unknown Object (File)
Jan 28 2024, 8:47 PM
Unknown Object (File)
Dec 26 2023, 11:29 AM
Unknown Object (File)
Dec 20 2023, 9:21 AM
Unknown Object (File)
Dec 20 2023, 5:25 AM
Unknown Object (File)
Nov 12 2023, 4:12 AM
Unknown Object (File)
Sep 4 2023, 12:08 AM
Subscribers

Details

Reviewers
jhb
arichardson
Group Reviewers
manpages

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

usr.bin/clang/lld/ld.lld.1
374

This is not a description of the option, rather it is the description of some not very important consequences of the object structure of the option is used.

379

dso also can have this flag set.

396

This description explains the object structure but not the flag intent. The flag sets the program main thread' stack size. The way it is done, by setting the size of the PT_GNU_STACK segment, is a detail that can be mentioned, but only as a curious addition.

usr.bin/clang/lld/ld.lld.1
374

The exact description of the option is the previous sentence, but this description explains the end use-case of the option, i.e., why the user might want to use it. Shall we document PT_GNU_RELRO handling in rtld(1) or elf(5) perhaps?

379

Do you think as part of object initialization might convey the right intent? The current sentence is still true for dsos I'd argue, but does not cover dlopened ones.

396

So just "Set the main thread's stack size to _size_." in your opinion?

I like referencing the implementation details so that users can follow the trail to understand what the option actually does -- for example "--enable-new-dtags" ought to explain what new dtags are.

Thus perhaps

Set the main thread's stack size to _size_. The size is recorded in the PT_GNU_STACK program segment.

usr.bin/clang/lld/ld.lld.1
374

No, the previous section is also an implementation detail.

It probably can be explained as 'Do not mark some part of the GOT read-only, after the initial relocations are processed.' Then the existing text might provide a details if user is so curious.

379

Either that, or 'during initial relocation of the object'.

396

Yes, it is better. 'The stack size is recorded as the size of PT_GNU_STACK ...'.

improvements from kib

usr.bin/clang/lld/ld.lld.1
379

Ok, I think I will go with my version - relocation processing during initial relocation seems like it might be confusing as to what the two relocation phases are.

usr.bin/clang/lld/ld.lld.1
374

Global variables such as const int* foo = &x;end up in .data.rel.ro and also the .eh_frame section needs to be relro on MIPS. For CHERI we also have another sections that is relro. I would not mention the GOT here since this also applies to other sections.

How about "Do not indicate that portions of the object should be mapped read-only after the initial relocation have been processed"

Also I'm not sure whether we should be using segment header or program header here. I believe most tools use program header? Maybe "The resulting object will not contain the PT_GNU_RELRO program header." ?

These changes will be included in the work to upstream the man page, tracked in https://reviews.llvm.org/D42963