[OE-core] Debug from failing hashequiv builds - server side problem?

[Joshua Watt]

On Sun, Dec 22, 2019, 6:49 AM Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:

> On Sun, 2019-12-22 at 12:08 +0000, Richard Purdie wrote:
> > On Sun, 2019-12-22 at 10:54 +0000, Richard Purdie wrote:
> > > I did a little digging on the weird hash equiv failure. I've
> > > attached two logs, one is the simplified console output, the other
> > > is the reams of debug.
>
> I did a bit more thinking about this. These hashes represent m4-native.
>
> We do have a problem that a given input hash for m4-native can
> represent two different output states depending on the architecture it
> was built on.
>
> For the same input hash, the output hash of these two things will never
> match. Nor will there ever be present sstate for them to trigger the
> report equiv mechanism.
>
> At query time in a clean build, the hashserver cannot know which of the
> two output hashes it needs to return the value for.
>

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.


> I can think of two possible options:
>
> a) When we report after running a task, we check if that input hash
> already has a value and then reuse it for the output hash mapping.
>

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)?




> b) We start adding some kind of suffix to the reported hashes for
> native output which is used within the hash equiv server but not
> sstate.
>

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?

This sounds related to the gcc-cross issues we had with the eSDK.

Is there a reason that the host arch isn't part of the taskhash?

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?



> I freely admit this needs much more thought...
>
> Cheers,
>
> Richard
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20191222/0a5d82da/attachment.html>