-
-
Notifications
You must be signed in to change notification settings - Fork 463
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
[Discussion] Support for .note.package
linker scripts
#505
Comments
Given that linker script, you know the exact contents of the |
Apparently I'm not the first person to think about passing an object file instead of a linker script. I found this discussion: https://reviews.llvm.org/D118490 It's not clear to me how and why it is difficult to pass an object file to the linker to include a ".note.package" section, though. If you can pass a But since it's a very obvious idea, I guess I may be missing something. From the mold's point of view, supporting a linker script feature is still overkill. Especially, the notion of "default linker script" is GNU linker's implementation specific. The GNU linker as a whole is implemented as an interpreter of the linker script, and Given this situation, I'd suggest we implement a new linker command line option, The new option should be much more straightforward than implementing it with some linker script hacking. Since this feature is intended to be used cross-distribution, and if Fedora and Debian wanted to use it for all packages, adding a native support to the linker can easily be justified IMO. And honestly it's not a big feature anyway. We can implement it pretty easily. How does this sound to you? |
Here is an experimental implementation of the Note that it's not submitted to the main branch, it's in |
Wow, the After reading through your deliberations and the lld discussion thread you linked above, I agree with you that a linker script is probably not the right thing to do here. I've toyed around with the assembler a bit and come up with this: .p2align 2
.section .note.package, "a"
.long 0x0004
.long .Lend - .Lbegin
.long 0xcafe1a7e
.string "FDO"
.Lbegin:
.string "{\"type\":\"package\",\"os\":\"fedora\",\"osVersion\":\"35\"}"
.Lend:
.p2align 2 When dumping this into a file named Maybe @bluca or @keszybz, who participated in the lld discussion on the |
A problem with an assembly language is that it's not cross platform even if your assembly contains only data directives and not code. I believe it's safer to create an empty object file and then copy a text to a .note.package using objcopy command if you take that route. |
The plan is to propose adding a command line like |
Then, maybe it's time to propose a new option to GNU perhaps with my implementation as FYI? |
F36 hasn't even shipped yet, so a bit too soon :-) But certainly in the coming months. Note that the linked patch doesn't do any parsing, so it needs some rework - the spec clearly says the payload is json, so the input should be validated for correctness |
I see no problem with using object file (*.o) with Haiku already does it. Every Haiku executable or shared library should export symbols Update: |
@bluca Input data validation is intentionally omitted in this patch and left it as a user's responsibility. Even if we do some validation, there's still lots of wrong ways to use the |
Yes, processors can handle nul json, that's not a problem (if you are aware of one that cannot, please let me know and I'll file a bug). The point is not to cover edge cases, the point is to ensure minimal validation as provided by a common library of choice. IE, the format needs to be validated, not the semantics of the content. |
There are still too many edge cases to test even if we just verify an input as a JSON string.
and so on and so on. And as I wrote, that format-level data validation doesn't prevent users from making a semantic error such as passing an empty JSON object |
There's no need to reimplement anything, there are existing libraries for this. The value proposition of a specific option that follows the open specification is to provide minimal validation of input, to verify adherence to the specifications. If it just shoves in anything passed through, it's really not adding much value. Anyway, on your tool you are free to do as you please of course, this is simply the approach I'll take when working on BSD, to provide something more useful. |
We don't want to add a dependency to a new library too casually. I believe that's also a stance of the GNU guys too. I think none of mold, lld or the GNU linkers wants to add a new dependency to |
Can't you simply use objcopy --add-section to add whatever section you want? You're presumably already going to post-process binaries to e.g. split out debuginfo, so it's not going to cost anything, and then you don't need to care about linkers, LDFLAGS or anything like that. And I don't see much point in linker trying to do the validation. If neither knows nor cares what the correct content is supposed to be, and your packaging system is going to be the one generating it, so it may just as well make sure it's correct. If somebody else is going to add the section, the linker is not going to stop them from messing it up. You also didn't seem to care about any validation with the linker script approach. |
@llunak I don't think you can use |
This may be true in general, but I wonder whether it would really be relevant for our concrete limited use case. I'm not an expert on all the nitty gritty details of the GNU assembler, but from my semi-limited experience I would assume the following:
Please correct me if I'm getting something wrong or missing something. The point I'm trying to make is this: if there is a realistic chance to get the functionality we need without having to introduce changes to four linkers (bfd, gold, lld, mold) in a coordinated manner, that's probably an option worth looking into. |
There is no chance, none of that works in reality, outside of 'hello world' tests that don't mean much, it's all been tried on real systems. What we have right now is what can actually work across ~30,000 packages using a thousand different build systems on 22 different binary architectures. Adding a new specific command line option, just like for |
.section works differently on non-ELF targets, but non-ELF targets are of no interest to Fedora. p2align and labels do, to my knowledge, work the same on every target.
Like .section, .string has failure cases; in this case, EBCDIC platforms. But, like .section, I don't think Fedora supports any non-ASCII-superset charsets. And if you do, https://sourceware.org/binutils/docs/as/ lists a .ascii command.
Let's check the docs.
They're probably something other than 32 bits if C int isn't 32 bits. But, again, I don't think that's relevant to anything Fedora supports. The 'at run time' segment probably means 'can be subject to relocations', but subtracting pointers in the same section and translation unit will give a proper constant on every plausible platform. Byte order is indeed target specific.
sicherha's code is hello world sized, and as such, has a quite reasonable probability of success. If you're aware of any counterexample, do tell. |
There's also |
I agree with this. |
I agree with the comment #505 (comment) and question the necessity of a new linker option. See also https://sourceware.org/pipermail/binutils/2022-May/120985.html
In binutils-gdb, See also https://src.fedoraproject.org/rpms/package-notes/pull-request/2 , there is a claim that adding a linker option makes more packages build than using a synthesized relocatable object file. |
Even though I don't think |
Indeed - you had an implementation for mold right? Could you please open a PR? Happy to review it - thanks! |
Is |
No, it's a cross-distro specification, currently also used in CBL-Mariner. We plan to push for adoption in other distributions too in the near future. |
@rui314 this is now merged in ld: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=9e2bb0cb5e74aed4158f08495534922d7108f928 |
People at Red Hat / Fedora are interested in experimenting with mold as part of the toolchain for building RPM packages. There is one major obstacle, though: the
.note.package
annotation mechanism that will be introduced in Fedora 36.In a nutshell,
.note.package
is a new section that gets added to every binary at link time. The section contains metadata about the program (e.g. package name, version, distribution) encoded as a small JSON document. This metadata can then be read out by various tools, for example bycoredumpctl
to display useful information about crashed programs to the user.This is all done by generating a small linker script (say,
notes.ld
) and then passing-Wl,-dT notes.ld
to the compiler driver. Here's an example of what such a script looks like:To be able to use mold as a drop-in replacement for the GNU linker, the following two missing features would have to be implemented:
The
-dT
,--default-script
command-line option:Since
-T
,--script
is already there, I reckon this wouldn't be too much effort.Support for non-trivial linker scripts (such as the one above) containing
SECTIONS
, constant values,INSERT AFTER
et cetera. I'm aware that you have previously taken the deliberate stance that mold will support only the absolute minimum set of features necessary for linking against/usr/lib64/libc.so
. Still, I would like to put this topic up for discussion as the feature set used by these particular scripts still seems relatively small.Is this something you consider worth pursuing?
The text was updated successfully, but these errors were encountered: