<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 2, 2020, 20:31 Michael Brown <<a href="mailto:mcb30@ipxe.org">mcb30@ipxe.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 03/05/2020 00:10, Neil Roza wrote:<br>
>     Hashing the build target name is not sufficient, because that would<br>
>     result in a collision between the same ROM built at different times<br>
>     from<br>
>     different source trees.<br>
> <br>
> Okay, understood. If I take your meaning correctly, then it would be <br>
> enough to hash a concatenation of the `$(SOURCE_DATE_EPOCH)` with the <br>
> target name. The relevant shell expression would become...<br>
> <br>
>      echo $(SOURCE_DATE_EPOCH) $@ | md5sum | head -c8<br>
> <br>
> Would that get it done? Or did I interpret your mention of "different <br>
> times" too literally?<br>
<br>
Different build configurations (e.g. config/*.h setting, or even <br>
DEBUG=... options specified on the make command line) also count as <br>
needing different build IDs.  Basically: anything that could possibly <br>
affect the runtime memory layout is relevant.<br>
<br>
It should really be a hash of the object that results from the link. <br>
The only reason it doesn't already use a hash is because the build ID is <br>
itself used as an input to the link (since that's how the value ends up <br>
in the binary).  It's possible that binutils now offers a clean and sane <br>
way to construct a hash value over the object: if so, then we could use <br>
that instead.  (If the result ends up being more than 32 bits then the <br>
consuming code would need to be updated accordingly.)</blockquote></div></div><div dir="auto"><br></div><div dir="auto">I think one Matt Turner has discovered the trick we need:</div><div dir="auto"><br></div><div dir="auto"><a href="https://github.com/mattst88/build-id/">https://github.com/mattst88/build-id/</a><br></div><div dir="auto"></div></div>