Skip to content

Conversation

maribu
Copy link
Member

@maribu maribu commented Jun 16, 2022

Contribution description

Let's consider firmwares as identical if their binfiles are matching, e.g. in case the .debug section ends up being different for whatever reason.

This hopefully makes sure false positives on hash mismatches are a thing of the past.

Testing procedure

Murdock should be happy. Even for ESP32 builds, every time.

Issues/PRs references

None

@maribu maribu added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Area: build system Area: Build system Impact: minor The PR is small in size and might only require a quick look of a knowledgeable reviewer CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Jun 16, 2022
@github-actions github-actions bot added the Area: tests Area: tests and testing framework label Jun 16, 2022
@maribu
Copy link
Member Author

maribu commented Jun 16, 2022

Note that creation of the binfile is one (rather simple) step more. But I do think that many ESP32 builds currently do get rebuild within the bounds of three failures due to this issue, and much less re-runs will be needed if the false positives don't happen anymore.

@MrKevinWeiss
Copy link
Contributor

Does everything have a BINFILE? I think maybe some might only have a HEXFILE, I think that FLASHFILE takes either the BINFILE or HEXFILE depending on the requirements for the board... Only an off-the-top-of-my-head answer.

@@ -74,7 +74,7 @@ test-with-config/check-config:
# this target only makes sense if an ELFFILE is actually created, thus guard by
# RIOTNOLINK="".
ifeq (,$(RIOTNOLINK))
test-input-hash: $(TESTS) $(TESTS_WITH_CONFIG) $(TESTS_AS_ROOT) $(ELFFILE) $(TEST_EXTRA_FILES)
test-input-hash: $(TESTS) $(TESTS_WITH_CONFIG) $(TESTS_AS_ROOT) $(BINFILE) $(TEST_EXTRA_FILES)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm right, BINFILE is not built in CI:

RIOT/Makefile.include

Lines 689 to 695 in 55b57e1

# By default always build ELFFILE, BINFILE and FLASHFILE
ifeq ($(RIOT_CI_BUILD),1)
# Don't build BINFILE on the CI to save some computation time
BUILD_FILES += $(ELFFILE) $(FLASHFILE)
else
BUILD_FILES += $(ELFFILE) $(BINFILE) $(FLASHFILE)
endif

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But if it is added as prerequisite, it should be built

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I tried it for AVR, only the FLASHFILE (.hex) is generated when RIOT_CI_BUILD is set.

@MrKevinWeiss
Copy link
Contributor

Whatever we change it to we may want to add a REMOVEME commit that prevents silent failures.

@gschorcht
Copy link
Contributor

Does everything have a BINFILE? I think maybe some might only have a HEXFILE, I think that FLASHFILE takes either the BINFILE or HEXFILE depending on the requirements for the board... Only an off-the-top-of-my-head answer.

Even though BINFILE is defined for any platform in $(RIOTBASE)/Makefile.include as

BINFILE ?= $(ELFFILE:.elf=.bin)

FLASHFILE is also generated in CI and would help to solve the problem for ESP32 since in ESPs the FLASHFILE corresponds to the BINFILE.

@maribu
Copy link
Member Author

maribu commented Jun 16, 2022

So we should go for FLASHFILE instead?

Given that the hash is used to guard tests runs, it may actually be quite beneficial to not run tests again if the machine code is unchanged. E.g. a whitespace change will result in a different ELF file with debug symbols, as the mapping of source lines to machine code will differ. Still, running the test again will (hopefully!) not yield a different result.

@MrKevinWeiss
Copy link
Contributor

Sure, maybe add a remove me commit before the has that sets FLASHFILE?=$RANDOM to be sure there is already something in there and it should fail if there isn't?

@maribu maribu force-pushed the makefiles/tests/tests.inc.mk branch from 7eb283c to 181dd44 Compare June 16, 2022 09:26
@maribu
Copy link
Member Author

maribu commented Jun 16, 2022

@MrKevinWeiss: Added and ifeq (,$(FLASHFILE)) $(error) endif instead. That is something we should be able to keep

Comment on lines 77 to 79
ifeq (,$(FLASHFILE))
$(error "FLASHFILE is not set!")
endif
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this check isn't needed here because this check is already done here

RIOT/Makefile.include

Lines 685 to 687 in 55b57e1

ifeq (,$(FLASHFILE))
$(error FLASHFILE is not defined for this board: $(FLASHFILE))
endif
before makefile/tests/test.inc.mk is included. Right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, using the undefined FLASHFILE variable in the error message doesn't make sense 😉

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intention was probably to use $(BOARD)

@maribu maribu changed the title makefiles/tests: use BINFILE for hash comparision instead of ELFFILE makefiles/tests: use FLASHFILE for hash comparision instead of ELFFILE Jun 16, 2022
@maribu maribu force-pushed the makefiles/tests/tests.inc.mk branch from 181dd44 to 55320dd Compare June 16, 2022 12:36
@benpicco benpicco added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Jun 16, 2022
@maribu maribu changed the title makefiles/tests: use FLASHFILE for hash comparision instead of ELFFILE makefiles/tests: use BINFILE for hash comparision instead of ELFFILE Jun 17, 2022
@maribu
Copy link
Member Author

maribu commented Jun 17, 2022

I changed back to BINFILE. The issue of mismatching hashes of the ELFFILE is not limited to ESP32 and other targets do use the ELFFILE as FLASHFILE.

Let's use consistently the BINFILE, sot hat we finally have the issue solved.

Also note that it will result in faster CI times when tests are running, as right now white-space-only changes will result in tests being re-run (due to changes in .debug of the ELFFILE), while it will no longer be the case with BINFILE.

@github-actions github-actions bot added Area: cpu Area: CPU/MCU ports Platform: MIPS Platform: This PR/issue effects MIPS-based platforms labels Jun 17, 2022
@maribu
Copy link
Member Author

maribu commented Jun 17, 2022

Cool, no BINFILE for MIPS. I am using the HEXFILE on MIPS now instead, that should also be robust against changes in debug symbols.

@gschorcht
Copy link
Contributor

Please squash.

maribu added 2 commits June 17, 2022 18:31
Let's consider firmwares as identical if their flash files are matching.
This will have the side effect that hash mismatches for ESP32 due to
different .debug sections in the ELFFILE are prevented, as for ESP32
the BINFILE is used.
@maribu maribu force-pushed the makefiles/tests/tests.inc.mk branch from 9b6393a to a247e87 Compare June 17, 2022 16:31
@gschorcht gschorcht merged commit e6823ed into RIOT-OS:master Jun 18, 2022
@gschorcht
Copy link
Contributor

@maribu Thanks for solving that problem.

@maribu
Copy link
Member Author

maribu commented Jun 18, 2022

Thx for the reviews!

@maribu maribu deleted the makefiles/tests/tests.inc.mk branch June 18, 2022 14:16
@benpicco
Copy link
Contributor

benpicco commented Jun 19, 2022

It appears as the issue is still present

@maribu
Copy link
Member Author

maribu commented Jun 19, 2022

Shit. I will try to take a look soonish

@gschorcht
Copy link
Contributor

Might it be that the PR has to be rebased?

@benpicco
Copy link
Contributor

Murdock will rebase automatically before building

@maribu
Copy link
Member Author

maribu commented Jun 20, 2022

I think I know what the issue is:

$ rm bin -rf && \
make BOARD=esp32-heltec-lora32-v2 BUILD_IN_DOCKER=1 RIOT_CI_BUILD=1 TEST_KCONFIG=1 test-input-hash && \
cat bin/esp32-heltec-lora32-v2/test-input-hash.sha1

make: *** No rule to make target '/home/maribu/Repos/software/RIOT/tests/driver_mhz19/bin/esp32-heltec-lora32-v2/tests_driver_mhz19.bin', needed by 'test-input-hash'.  Stop.

Since there is no explicit rule to create the binfile, make cannot now for what job it has to wait to finish before starting to compare the hash value.

Doing a make all will create that binfile. And the hashes are reproducible identical.

@maribu
Copy link
Member Author

maribu commented Jun 20, 2022

False alarm, it does work fine without BUILD_IN_DOCKER=1. When manually starting the docker container and calling make BOARD=esp32-heltec-lora32-v2 RIOT_CI_BUILD=1 TEST_KCONFIG=1 test-input-hash in there, it does just work.

@maribu
Copy link
Member Author

maribu commented Jun 21, 2022

I opened #18236 in the hope it can shed some light on the remaining issue. I cannot reproduce mismatching values in test-input-hash.sha1 anymore and I have the feeling that the issue is something like reading it out before its contents have been fully written to or so.

@gschorcht
Copy link
Contributor

I cannot reproduce mismatching values in test-input-hash.sha1 anymore

Me too.

and I have the feeling that the issue is something like reading it out before its contents have been fully written to or so.

What confirms this assumption is that the problem seems to occur only sporadically. Some compilations have already been successful, others still show the problem. It seems to occur mostly with esp32-heltec-lora32-v2. Might there be a dependency problem of BINFILE?

@chrysn chrysn added this to the Release 2022.07 milestone Aug 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: build system Area: Build system Area: cpu Area: CPU/MCU ports Area: tests Area: tests and testing framework CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Impact: minor The PR is small in size and might only require a quick look of a knowledgeable reviewer Platform: MIPS Platform: This PR/issue effects MIPS-based platforms Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants