[PATCH 01/10] build: Generate build hash

Chris Johns chrisj at rtems.org
Thu Feb 25 23:20:45 UTC 2021


On 25/2/21 7:42 pm, Sebastian Huber wrote:
> On 25/02/2021 05:13, Chris Johns wrote:
> 
>> On 25/2/21 12:57 am, Sebastian Huber wrote:
>>> Update #4265.
>>> ---
>>>   wscript | 27 ++++++++++++++++++++++++++-
>>>   1 file changed, 26 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/wscript b/wscript
>>> index 6626fafb74..83c7c446bb 100755
>>> --- a/wscript
>>> +++ b/wscript
>>> @@ -1359,6 +1359,30 @@ def get_compiler(conf, cp, variant):
>>>       return value
>>>     +def _generate_build_hash(conf):
>>> +    import hashlib
>>> +    import base64
>>> +
>>> +    build_hash = ""
>>> +    for key in sorted(conf.env):
>>> +        build_hash = build_hash + key + str(conf.env[key])
>> I am pleased to see the environment is being addressed but on some modern
>> operating systems the environment has become a bit of a beast. This means
>> comparable values will be near impossible if the whole environment is included
>> in the build hash.
>>
>> Should we look to use a list that is contained? A list that effects the code on
>> the target? In a purest sense a hash created from the CU pieces in all target
>> libraries would be ideal however this is recursive.
> This is a good idea. Maybe we should iterate over all start files and libraries
> generated by the build and then create a hash of all executable sections. Then
> we recompile one object with a command line define with the build hash and
> replace this object in librtemscpu.a.

Nice. I wonder if this could then include the gcc/newlib library mix for that BSP?

The hash generator could be added to `rtems-exe-info` without too much effort.
The toolkit can handle ELF object and archives out of the box and the code to
read a section into memory is somewhere in the `ra` tools so at hand.

Which ELF sections flags should be matched? Just executable, const, string etc?

>> Any chance of a build label set in the config.ini? :)
> You want something like a rtems_get_build_label() which returns the value of
> RTEMS_BUILD_LABEL set in a config.ini (or a default, e.g. "arch/bsp")?

Yes I would. Felix (gemini) and I are working at the moment to find why his
RTEMS 5 build is not working and this sort of enumeration would help. The
ability to label an RTEMS build in a simple non-invasive manner would help all
RTEMS deployments.

>>
>>> +    for discard in [
>>> +        conf.env.PREFIX,
>>> +        conf.bldnode.make_node(conf.env.VARIANT).abspath(),
>>> +        conf.path.abspath(),
>>> +    ]:
>>> +        build_hash = build_hash.replace(discard, "")
>> I do not follow this piece of logic.
> It removes prefix, source and build paths.

OK.

>>> +    state = hashlib.sha256()
>>> +    state.update(build_hash.encode("utf-8"))
>> Why the `utf-8` encode and then decode later?
> The hash update needs a byte stream not a string. The define needs a string and
> not a byte stream.

Thanks

Chris


More information about the devel mailing list