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 > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
