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.

Sign up for GitHub

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

Jump to bottom

docs: clarify JSON terms in COREDUMP_PACKAGE_METADATA #21578

Merged
merged 2 commits into from
Nov 30, 2021
Merged

docs: clarify JSON terms in COREDUMP_PACKAGE_METADATA #21578

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
bedd92b
docs: clarify JSON terms in COREDUMP_PACKAGE_METADATA
bluca Nov 30, 2021
45f822c
docs: clarify ELF note usage in COREDUMP_PACKAGE_METADATA
bluca Nov 30, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
19 changes: 12 additions & 7 deletions docs/COREDUMP_PACKAGE_METADATA.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,11 +34,11 @@ multiple implementers might use it when building packages, or core file analyzer
so on.

The metadata will be embedded in a single, new, 4-bytes-aligned, allocated, 0-padded,
read-only ELF header section, in a key-value JSON format. Implementers working on parsing
core files should not assume a specific list of keys, but parse anything that is included
in the section. Implementers working on build tools should strive to use the same key
names, for consistency. The most common will be listed here. When corresponding to the
content of os-release, the values should match, again for consistency.
read-only ELF header section, in a name-value JSON object format. Implementers working on parsing
core files should not assume a specific list of names, but parse anything that is included
in the section, and should look for the note using the `note type`. Implementers working on
build tools should strive to use the same names, for consistency. The most common will be
listed here. When corresponding to the content of os-release, the values should match, again for consistency.

If available, the metadata should also include the debuginfod server URL that can provide
the original executable, debuginfo and sources, to further facilitate debugging.
Expand All @@ -47,9 +47,9 @@ the original executable, debuginfo and sources, to further facilitate debugging.

```
SECTION: `.note.package`
bluca marked this conversation as resolved.
Show resolved Hide resolved
node-id: `0xcafe1a7e`
note type: `0xcafe1a7e`
Owner: `FDO` (FreeDesktop.org)
Value: a JSON string with the structure described below
Value: a single JSON object encoded as a zero-terminated UTF-8 string
```

* JSON payload
Expand All @@ -67,6 +67,11 @@ Value: a JSON string with the structure described below
}
```

The format is a single JSON object, encoded as a zero-terminated `UTF-8` string.
Each name in the object shall be unique as per recommendations of
[RFC8259](https://datatracker.ietf.org/doc/html/rfc8259#section-4). Strings shall
not contain any control character, nor use `\uXXX` escaping.

When it comes to JSON numbers, this specification assumes that JSON parsers
processing this information are capable of reproducing the full signed 53bit
integer range (i.e. -2⁵³+1…+2⁵³-1) as well as the full 64bit IEEE floating
Expand Down