On 28.03.23 23:46, Chris Johns wrote:
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.
It looks like we are not the only ones needing such a thing. Nick
Clifton suggested to use this:
https://systemd.io/ELF_PACKAGE_METADATA/
https://sourceware.org/pipermail/binutils/2023-March/126822.html
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
