Use objcopy from rust's llvm-tools-preview? #449
Comments
|
iirc @cbiffle had said that the llvm version of these tools doesn't do the right things for some stuff we need. I don't remember more context than that. |
|
I did find ac53573 |
|
I believe we've recently ended our reliance on |
hawkw
added a commit
that referenced
this issue
Feb 26, 2024
Currently, the `#[derive(ringbuf::Count)]` attribute is pretty simple: it generates a single counter for every variant of the annotated `enum` type. For some of the ringbuf events we would like to generate counters for, this is sufficient. However, there are a few things that would be nice to have that we can't currently do with the derive attribute: - Most ringbuf entry enum types have an "Empty"/"None" variant that's used for initializing the ringbuffer, but are never actually recorded at runtime. We could save a few bytes by not generating a counter for these variants. - Many ringbuf entry enum variants contain a nested enum variant. such as a variant representing an error which contains an error kind enum, or, the motivating example, `Log::MgsMessage(MgsMessage)` in control-plane-agent. In this case, we would like to be able to generate a counter of each MGS message variant, which is not currently possible with the current `#[derive(ringbuf::Count)]` attribute. This commit adds new helper attributes to the derive macro: `#[count(skip)]` and `#[count(children)]`. The `#[count(skip)]` attribute can be placed on an enum variant to indicate that a counter *shouldn't* be generated for it. The `#[count(children)]` attribute can be placed on an enum variant that has a single field, to indicate that a _nested_ set of counters should be generated for that variant's inner field. When the `#[count(children)]` attribute is used, the inner field must also implement the `Count` trait. If it does, the field on the counter type for that variant will be the child type's `Count::Counters` type, rather than an `AtomicU32`, and we will increment the nested counter. My Humility PR #449 adds nice support for interpreting and displaying these nested counters.
hawkw
added a commit
that referenced
this issue
Feb 27, 2024
Currently, the `#[derive(ringbuf::Count)]` attribute is pretty simple: it generates a single counter for every variant of the annotated `enum` type. For some of the ringbuf events we would like to generate counters for, this is sufficient. However, there are a few things that would be nice to have that we can't currently do with the derive attribute: - Most ringbuf entry enum types have an "Empty"/"None" variant that's used for initializing the ringbuffer, but are never actually recorded at runtime. We could save a few bytes by not generating a counter for these variants. - Many ringbuf entry enum variants contain a nested enum variant. such as a variant representing an error which contains an error kind enum, or, the motivating example, `Log::MgsMessage(MgsMessage)` in control-plane-agent. In this case, we would like to be able to generate a counter of each MGS message variant, which is not currently possible with the current `#[derive(ringbuf::Count)]` attribute. This commit adds new helper attributes to the derive macro: `#[count(skip)]` and `#[count(children)]`. The `#[count(skip)]` attribute can be placed on an enum variant to indicate that a counter *shouldn't* be generated for it. The `#[count(children)]` attribute can be placed on an enum variant that has a single field, to indicate that a _nested_ set of counters should be generated for that variant's inner field. When the `#[count(children)]` attribute is used, the inner field must also implement the `Count` trait. If it does, the field on the counter type for that variant will be the child type's `Count::Counters` type, rather than an `AtomicU32`, and we will increment the nested counter. My Humility PR #449 adds nice support for interpreting and displaying these nested counters.
hawkw
added a commit
that referenced
this issue
Feb 27, 2024
Currently, the `#[derive(ringbuf::Count)]` attribute is pretty simple: it generates a single counter for every variant of the annotated `enum` type. For some of the ringbuf events we would like to generate counters for, this is sufficient. However, there are a few things that would be nice to have that we can't currently do with the derive attribute: - Most ringbuf entry enum types have an "Empty"/"None" variant that's used for initializing the ringbuffer, but are never actually recorded at runtime. We could save a few bytes by not generating a counter for these variants. - Many ringbuf entry enum variants contain a nested enum variant. such as a variant representing an error which contains an error kind enum, or, the motivating example, `Log::MgsMessage(MgsMessage)` in control-plane-agent. In this case, we would like to be able to generate a counter of each MGS message variant, which is not currently possible with the current `#[derive(ringbuf::Count)]` attribute. This commit adds new helper attributes to the derive macro: `#[count(skip)]` and `#[count(children)]`. The `#[count(skip)]` attribute can be placed on an enum variant to indicate that a counter *shouldn't* be generated for it. The `#[count(children)]` attribute can be placed on an enum variant that has a single field, to indicate that a _nested_ set of counters should be generated for that variant's inner field. When the `#[count(children)]` attribute is used, the inner field must also implement the `Count` trait. If it does, the field on the counter type for that variant will be the child type's `Count::Counters` type, rather than an `AtomicU32`, and we will increment the nested counter. My Humility PR #449 adds nice support for interpreting and displaying these nested counters.
hawkw
added a commit
that referenced
this issue
Feb 28, 2024
Currently, the `#[derive(ringbuf::Count)]` attribute is pretty simple: it generates a single counter for every variant of the annotated `enum` type. For some of the ringbuf events we would like to generate counters for, this is sufficient. However, there are a few things that would be nice to have that we can't currently do with the derive attribute: - Most ringbuf entry enum types have an "Empty"/"None" variant that's used for initializing the ringbuffer, but are never actually recorded at runtime. We could save a few bytes by not generating a counter for these variants. - Many ringbuf entry enum variants contain a nested enum variant. such as a variant representing an error which contains an error kind enum, or, the motivating example, `Log::MgsMessage(MgsMessage)` in control-plane-agent. In this case, we would like to be able to generate a counter of each MGS message variant, which is not currently possible with the current `#[derive(ringbuf::Count)]` attribute. This commit adds new helper attributes to the derive macro: `#[count(skip)]` and `#[count(children)]`. The `#[count(skip)]` attribute can be placed on an enum variant to indicate that a counter *shouldn't* be generated for it. The `#[count(children)]` attribute can be placed on an enum variant that has a single field, to indicate that a _nested_ set of counters should be generated for that variant's inner field. When the `#[count(children)]` attribute is used, the inner field must also implement the `Count` trait. If it does, the field on the counter type for that variant will be the child type's `Count::Counters` type, rather than an `AtomicU32`, and we will increment the nested counter. My Humility PR #449 adds nice support for interpreting and displaying these nested counters.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Rust ships llvm-tools-preview (rust-lang/rust#85658) which includes llvm-objcopy. This component should be installable via rust-toolchain.yaml. Using this in xtask would remove the need for installing host system packages.
The text was updated successfully, but these errors were encountered: