[PATCH] Add support for ELF notes
Chris Johns
chrisj at rtems.org
Tue Mar 28 21:46:08 UTC 2023
On 29/3/2023 5:36 am, Sebastian Huber wrote:
> On 28.03.23 09:26, Chris Johns wrote:
>> On 28/3/2023 6:20 pm, Sebastian Huber wrote:
>>> On 28.03.23 09:03, Chris Johns wrote:
>>>> On 28/3/2023 5:48 pm, Sebastian Huber wrote:
>>>>> On 25.03.23 00:39, Chris Johns wrote:
>>>>>> On 24/3/2023 7:32 pm, Sebastian Huber wrote:
>>>>>>> On 23.03.23 20:07, Chris Johns wrote:
>>>>>>>> On 24/3/2023 3:57 am, Sebastian Huber wrote:
>>>>>>>>> On 23.03.23 17:52, Will wrote:
>>>>>>>>>> Great idea to store this information in the executable itself. Does this
>>>>>>>>>> need
>>>>>>>>>> a RTEMS_TEST_STATE_LINK_ONLY test state or something similar for
>>>>>>>>>> minimum.exe?
>>>>>>>>> With the notes you can build the test. The test runner would look at the
>>>>>>>>> notes
>>>>>>>>> and then decide if it makes sense to run the test or not. It could still
>>>>>>>>> run the
>>>>>>>>> minimum.exe and see if it terminates.
>>>>>>>> I welcome notes support. Thanks for adding it.
>>>>>>>>
>>>>>>>> How will we control and manage the notes we support?
>>>>>>> In the new elfnote.h header file there are defines for the note type
>>>>>>> (domain-specific integer).
>>>>>> Great.
>>>>>>
>>>>>>>> Should we document the top level notes domains (?) with some we control and
>>>>>>>> restrict and others users can use? For example `note.rtems.test`,
>>>>>>>> `note.rtems.kernel`, `note.rtems.bsp`, and `note.rtems.user`?
>>>>>>> The section name doesn't matter. You can divide the number space of the note
>>>>>>> type for this.
>>>>>> Does this mean we define the numbers or number ranges or is it left open?
>>>>>> I am
>>>>>> not sure I am following this bit.
>>>>> The patch has this:
>>>>>
>>>>> #define ELF_NOTE_RTEMS_TYPE( _index ) ( ( _index ) + 0x10000 )
>>>>>
>>>>> We basically have 32-bits available. We could also use something like this:
>>>>>
>>>>> #define ELF_NOTE_RTEMS_BASE_TYPE( _index ) ( ( _index ) + 0x10000000 )
>>>>>
>>>>> #define ELF_NOTE_RTEMS_TEST_TYPE( _index ) ( ( _index ) + 0x20000000 )
>>>>>
>>>>> #define ELF_NOTE_RTEMS_USER_TYPE( _index ) ( ( _index ) + 0x30000000 )
>>>>>
>>>>> ...
>>>>>
>>>> Nice.
>>> Maybe we should also encode the data type here, for example:
>>>
>>> #define ELF_NOTE_DATA_TYPE_BOOL 0
>>> #define ELF_NOTE_DATA_TYPE_INT8 1
>>> #define ELF_NOTE_DATA_TYPE_UINT8 2
>>> #define ELF_NOTE_DATA_TYPE_INT16 3
>>> #define ELF_NOTE_DATA_TYPE_UINT16 4
>>> #define ELF_NOTE_DATA_TYPE_INT32 5
>>> #define ELF_NOTE_DATA_TYPE_UINT32 6
>>> #define ELF_NOTE_DATA_TYPE_INT64 7
>>> #define ELF_NOTE_DATA_TYPE_UINT64 8
>>> #define ELF_NOTE_DATA_TYPE_FLOAT32 9
>>> #define ELF_NOTE_DATA_TYPE_FLOAT32 10
>>> #define ELF_NOTE_DATA_TYPE_FLOAT64 11
>>> #define ELF_NOTE_DATA_TYPE_FLOAT64 12
>>> #define ELF_NOTE_DATA_TYPE_STRING 13
>>> #define ELF_NOTE_DATA_TYPE_BINARY 14
>>>
>>> #define ELF_NOTE_RTEMS_BASE_TYPE( _data_type, _index ) \
>>> ( ( ( _data_type ) << 28 ) | ( ( _index ) + 0x1000000 ) )
>>>
>>> This could be used by the host tool to more easily produce the right JSON data.
>>>
>> Good idea. I cannot think of anything else as scoping would tend to reduce to a
>> new type.
>
> Another option would be to add a GNU note type for JSON data. The note
> description would be an arbitrary JSON string.
Wooo that is interesting. JSON can be useful in these situations. I like it.
Chris
> For example:
>
> diff --git a/binutils/readelf.c b/binutils/readelf.c
> index cafba9a4f56..1d977376b77 100644
> --- a/binutils/readelf.c
> +++ b/binutils/readelf.c
> @@ -20261,6 +20261,10 @@ print_gnu_note (Filedata * filedata, Elf_Internal_Note
> *pnote)
> print_gnu_property_note (filedata, pnote);
> break;
>
> + case NT_GNU_JSON:
> + print_json_note (filedata, pnote);
> + break;
> +
> default:
> /* Handle unrecognised types. An error message should have already been
> created by get_gnu_elf_note_type(), so all that we need to do is to
> diff --git a/include/elf/common.h b/include/elf/common.h
> index ebcd8f9e82c..c5671447074 100644
> --- a/include/elf/common.h
> +++ b/include/elf/common.h
> @@ -805,6 +805,7 @@
> #define NT_GNU_BUILD_ID 3 /* Generated by ld --build-id. */
> #define NT_GNU_GOLD_VERSION 4 /* Generated by gold. */
> #define NT_GNU_PROPERTY_TYPE_0 5 /* Generated by gcc. */
> +#define NT_GNU_JSON 6 /* Contains arbitrary JSON data. */
>
> #define NT_GNU_BUILD_ATTRIBUTE_OPEN 0x100
> #define NT_GNU_BUILD_ATTRIBUTE_FUNC 0x101
>
More information about the devel
mailing list