On Sun, Dec 22, 2019, 6:49 AM Richard Purdie < [email protected]> 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 > >
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
