<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 22, 2019, 6:49 AM Richard Purdie <<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank" rel="noreferrer">richard.purdie@linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, 2019-12-22 at 12:08 +0000, Richard Purdie wrote:<br>
> On Sun, 2019-12-22 at 10:54 +0000, Richard Purdie wrote:<br>
> > I did a little digging on the weird hash equiv failure. I've<br>
> > attached two logs, one is the simplified console output, the other<br>
> > is the reams of debug.<br>
<br>
I did a bit more thinking about this. These hashes represent m4-native.<br>
<br>
We do have a problem that a given input hash for m4-native can<br>
represent two different output states depending on the architecture it<br>
was built on.<br>
<br>
For the same input hash, the output hash of these two things will never<br>
match. Nor will there ever be present sstate for them to trigger the<br>
report equiv mechanism.<br>
<br>
At query time in a clean build, the hashserver cannot know which of the<br>
two output hashes it needs to return the value for.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">In the case of multiple taskhashes mapping to different output hashes, the server is supposed to simply return the oldest unihash. If it's not doing that, there might be a bug.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I can think of two possible options:<br>
<br>
a) When we report after running a task, we check if that input hash<br>
already has a value and then reuse it for the output hash mapping.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I don't quite follow this one, can you be a little more precise with what hashes you are referring to (e.g. taskhash, unihash, outhash)?</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
b) We start adding some kind of suffix to the reported hashes for<br>
native output which is used within the hash equiv server but not<br>
sstate.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Just for clarification, this is because "native" can either be x86_64 or aarch64 but the actual arch (HOST_ARCH ?) isn't part of the taskhash calculation?</div><div dir="auto"><br></div><div dir="auto">This sounds related to the gcc-cross issues we had with the eSDK.</div><div dir="auto"><br></div><div dir="auto">Is there a reason that the host arch isn't part of the taskhash?</div><div dir="auto"><br></div><div dir="auto">I think it might be possible to report additional inputs in the hashes reported to the server. The server doesn't really care if it's the exact taskhash, as long as the client is consistent. Perhaps that would help with the gcc-cross issue as well?</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I freely admit this needs much more thought...<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
</blockquote></div></div></div>