* bug#49515: [core-updates] mescc-tools tests fail
@ 2021-07-10 23:56 Ludovic Courtès
2021-07-18 21:04 ` Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2021-07-10 23:56 UTC (permalink / raw)
To: 49515
On commit 9b4c3c675c05870e5983c21ce4ff944e0b0bc2fa of ‘core-updates’,
mescc-tools fails tests, with generated binaries segfaulting:
--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix build mescc-tools
[…]
+ . ./sha256.sh
++ set -ex
++ ./bin/get_machine
+ ./bin/M1 -f test/test3/defs -f test/test3/lisp.s --BigEndian --architecture knight-native -o test/test3/hold
+ '[' amd64 = amd64 ']'
+ ./test/results/test1-binary
+ ./bin/hex2 -f elf_headers/elf32.hex2 -f test/test2/hold --LittleEndian --architecture x86 --BaseAddress 0x8048000 -o test/results/test2-binary --exec_enable
test/test1/hello.sh: line 37: 125 Segmentation fault ./test/results/test1-binary < test/test1/hex0.hex0 > test/test1/proof1
++ ./bin/get_machine
make: *** [makefile:104: test1-binary] Error 139
make: *** Waiting for unfinished jobs....
+ '[' amd64 = x86 ']'
+ exit 0
+ . ./sha256.sh
++ set -ex
++ ./bin/get_machine
+ '[' amd64 = x86 ']'
+ exit 0
+ ./bin/hex2 -f test/test3/hold --BigEndian --architecture knight-native --BaseAddress 0 -o test/results/test3-binary
+ . ./sha256.sh
++ set -ex
test/test3/hello.sh: line 23: GET_MACHINE_FLAGS: unbound variable
+ '[' '' = 'knight*' ']'
+ exit 0
Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("test" "-j" "4" "PREFIX=/gnu/store/xps0k41ydjl14lx7cnrgclgsi5cnkib7-mescc-tools-0.7.0" "CC=gcc") exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 0.1 seconds
command "make" "test" "-j" "4" "PREFIX=/gnu/store/xps0k41ydjl14lx7cnrgclgsi5cnkib7-mescc-tools-0.7.0" "CC=gcc" failed with status 2
builder for `/gnu/store/lir8pmc63k1bcj4ml9gsx1769aw9ndj2-mescc-tools-0.7.0.drv' failed with exit code 1
build of /gnu/store/lir8pmc63k1bcj4ml9gsx1769aw9ndj2-mescc-tools-0.7.0.drv failed
--8<---------------cut here---------------end--------------->8---
This is a dependency of the ‘bootstrap-tarballs’ package.
Ludo’.
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#49515: [core-updates] mescc-tools tests fail 2021-07-10 23:56 bug#49515: [core-updates] mescc-tools tests fail Ludovic Courtès @ 2021-07-18 21:04 ` Ludovic Courtès 2021-07-18 21:08 ` Ludovic Courtès 2021-07-19 4:49 ` Jan Nieuwenhuizen 0 siblings, 2 replies; 6+ messages in thread From: Ludovic Courtès @ 2021-07-18 21:04 UTC (permalink / raw) To: 49515 Hi, Ludovic Courtès <ludo@gnu.org> skribis: > On commit 9b4c3c675c05870e5983c21ce4ff944e0b0bc2fa of ‘core-updates’, > mescc-tools fails tests, with generated binaries segfaulting: > > $ ./pre-inst-env guix build mescc-tools > > […] > > + . ./sha256.sh > ++ set -ex > ++ ./bin/get_machine > + ./bin/M1 -f test/test3/defs -f test/test3/lisp.s --BigEndian --architecture knight-native -o test/test3/hold > + '[' amd64 = amd64 ']' > + ./test/results/test1-binary > + ./bin/hex2 -f elf_headers/elf32.hex2 -f test/test2/hold --LittleEndian --architecture x86 --BaseAddress 0x8048000 -o test/results/test2-binary --exec_enable > test/test1/hello.sh: line 37: 125 Segmentation fault ./test/results/test1-binary < test/test1/hex0.hex0 > test/test1/proof1 [...] > builder for `/gnu/store/lir8pmc63k1bcj4ml9gsx1769aw9ndj2-mescc-tools-0.7.0.drv' failed with exit code 1 I found that this upstream commit, which made it in version 1.1.0, fixes the segfault: commit e633669dfdf16f503a7d740b9058e343536533b4 Author: nimaje <nimaje@bootstrappable.irc_channel> Date: Thu Oct 15 19:12:18 2020 -0400 Fix ELF headers to be more well behaved I tried backporting it (patch below) but that leads to: --8<---------------cut here---------------start------------->8--- test/test2/hello.sh + ./bin/M1 -f test/test2/hex.M1 --LittleEndian --Architecture 1 -o test/test2/hold + ./bin/hex2 -f elf_headers/elf32.hex2 -f test/test2/hold --LittleEndian --Architecture 1 --BaseAddress 0x8048000 -o test/results/test2-binary --exec_enable ++ ./bin/get_machine + '[' x86_64 = x86_64 ']' + ./test/results/test2-binary + r=0 + '[' 0 = 0 ']' ++ sha256sum -c test/test2/proof.answer sha256sum: WARNING: 1 computed checksum did NOT match + out='test/test2/proof: FAILED' + '[' 'test/test2/proof: FAILED' = 'test/test2/proof: OK' ']' + exit 2 make: *** [makefile:94: test2-binary] Error 2 Test suite failed, dumping logs. error: in phase 'check': uncaught exception: %exception #<&invoke-error program: "make" arguments: ("test" "-j" "1" "PREFIX=/gnu/store/mklrxb6k2a7f1nspm5az1w3pjgfqyx07-mescc-tools-0.5.2-0.bb062b0") exit-status: 2 term-signal: #f stop-signal: #f> phase `check' failed after 0.0 seconds command "make" "test" "-j" "1" "PREFIX=/gnu/store/mklrxb6k2a7f1nspm5az1w3pjgfqyx07-mescc-tools-0.5.2-0.bb062b0" failed with status 2 builder for `/gnu/store/5pkxsjjhlirznxfblsm8g4x0dq8nlz6g-mescc-tools-0.5.2-0.bb062b0.drv' failed with exit code 1 build of /gnu/store/5pkxsjjhlirznxfblsm8g4x0dq8nlz6g-mescc-tools-0.5.2-0.bb062b0.drv failed --8<---------------cut here---------------end--------------->8--- Should we upgrade instead? If we do, what’s the potential for breakage? Should ‘mes-rb5’ be kept on an older version? WDYT, Janneke? :-) Thanks, Ludo’. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#49515: [core-updates] mescc-tools tests fail 2021-07-18 21:04 ` Ludovic Courtès @ 2021-07-18 21:08 ` Ludovic Courtès 2021-07-19 4:49 ` Jan Nieuwenhuizen 1 sibling, 0 replies; 6+ messages in thread From: Ludovic Courtès @ 2021-07-18 21:08 UTC (permalink / raw) To: 49515 [-- Attachment #1: Type: text/plain, Size: 132 bytes --] Ludovic Courtès <ludo@gnu.org> skribis: > I tried backporting it (patch below) but that leads to: And here’s the patch. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: the patch --] [-- Type: text/x-patch, Size: 6551 bytes --] commit e633669dfdf16f503a7d740b9058e343536533b4 Author: nimaje <nimaje@bootstrappable.irc_channel> Date: Thu Oct 15 19:12:18 2020 -0400 Fix ELF headers to be more well behaved diff --git a/elf_headers/elf32-debug.hex2 b/elf_headers/elf32-debug.hex2 index 667b032..9fe0183 100644 --- a/elf_headers/elf32-debug.hex2 +++ b/elf_headers/elf32-debug.hex2 @@ -33,7 +33,7 @@ 01 # e_ident[EI_DATA] Indicating little endianness 01 # e_ident[EI_VERSION] Indicating original elf -00 # e_ident[EI_OSABI] Set at 0 because none cares +03 # e_ident[EI_OSABI] Set at 3 because FreeBSD is strict 00 # e_ident[EI_ABIVERSION] See above 00 00 00 00 00 00 00 # e_ident[EI_PAD] diff --git a/elf_headers/elf32.hex2 b/elf_headers/elf32.hex2 index 45d365c..6432523 100644 --- a/elf_headers/elf32.hex2 +++ b/elf_headers/elf32.hex2 @@ -34,7 +34,7 @@ 01 # e_ident[EI_DATA] Indicating little endianness 01 # e_ident[EI_VERSION] Indicating original elf -00 # e_ident[EI_OSABI] Set at 0 because none cares +03 # e_ident[EI_OSABI] Set at 3 because FreeBSD is strict 00 # e_ident[EI_ABIVERSION] See above 00 00 00 00 00 00 00 # e_ident[EI_PAD] diff --git a/elf_headers/elf64.hex2 b/elf_headers/elf64.hex2 index 23d2a4a..6c10442 100644 --- a/elf_headers/elf64.hex2 +++ b/elf_headers/elf64.hex2 @@ -27,7 +27,7 @@ 01 ## e_ident[EI_DATA] Indicating little endianness 01 ## e_ident[EI_VERSION] Indicating original elf -00 ## e_ident[EI_OSABI] Set at 0 because none cares +03 ## e_ident[EI_OSABI] Set at 3 because FreeBSD is strict 00 ## e_ident[EI_ABIVERSION] See above 00 00 00 00 00 00 00 ## e_ident[EI_PAD] @@ -53,7 +53,7 @@ ## Program Header :ELF_program_headers 01 00 00 00 ## p_type -06 00 00 00 ## Flags +07 00 00 00 ## ph_flags: PF-X|PF-W|PF-R = 7 00 00 00 00 00 00 00 00 ## p_offset &ELF_base 00 00 00 00 ## p_vaddr diff --git a/test/test.answers b/test/test.answers index d449db4..9b366f7 100644 --- a/test/test.answers +++ b/test/test.answers @@ -1,12 +1,12 @@ -b5a1dbfb4b9e42f839cd41f704b2d20d67705be5f5214d194d08026006e823a2 test/results/test0-binary -34cd00306059776d0a1c54dff9d1a4ecb9915fa5b92746b6999c67e535f56b7c test/results/test1-binary -2505fa977f1eb9b8eb9cc338af6f606fb8341f1e2f341f71b249c50e7af5e0a7 test/results/test10-binary -e27aa179b47bd21b8a43f460ef11622dcd13767cb515000ae583dc2706b89657 test/results/test11-binary -1757e43a482f632286933a56d5da1e87d6385366adfa830df363ba6060a12784 test/results/test2-binary +054359eb2b4e4f75aa212a41f90654b18b1efdde7ba08aac12bd9c21b1a12cf6 test/results/test0-binary +56c3021ae5d31e1f57552f103e309603636de5ff38948f1be3e810d9ea0e670b test/results/test1-binary +2027e0c8d6295f041d338a430c5a3d3aae042294e5ba4ad1eb08bed16b147671 test/results/test10-binary +ce9e76b600fdf67589e9180571bed092e9e091a3bf70dc852facd1b678d9df7b test/results/test11-binary +7247e7537ef3a83d4c557941bf59a591d6db0688c7a12362af7d14adac238ad4 test/results/test2-binary 2b80849180d5fb3757bcca2471b6337808e5b5ca80b18d93fa82ddef0435b84b test/results/test3-binary -7db345c74d6ee13f21857f9f9419db2bb0890782923485b05dd9eb29b6436efa test/results/test4-binary -a7b5c22218bdad3cb8f74a7951fa1425fee5adafdf206420fd020d92b4a13b5e test/results/test5-binary -7123c8033949312d9325bffe02246bf599463f214eb0b281e7187c7b06818bae test/results/test6-binary -5992d312f114019d955195d50af25f68c3ab079b1e115ddf31f1aca2431d5dca test/results/test7-binary +310bea3129335b2cbda70fd591b2cf079b6f7fc19b22f12061a5379ba96dbdae test/results/test4-binary +1b09d2b8a3848d691d5d5927f80b6acaad57174b7653d88fe07cd1f6f4bd6f3d test/results/test5-binary +61d70db94077ee71b5522f44344baf3943c02559fb1c3e311cfe2fb6cb652d55 test/results/test6-binary +5cba7bcb9de863c721613b5fafa17277e9e83336e32c8e7e59ee76d003ed5f29 test/results/test7-binary a71dc25bcba2a7298b9b9024a7927e215c5081a9ff90a6afa9b583be6c0a7e06 test/results/test8-binary -b3ec35dc3ce5335ad384b8b2b8b7930aa414014e2bafa61bb6a2b7be8674b88f test/results/test9-binary +7fb2aa7451ea132a98f3900b140c8eb3d50751aa6adeac23fd2d766fce2635d4 test/results/test9-binary diff --git a/test/test1/hex0.hex0 b/test/test1/hex0.hex0 index 7060a6d..611a86f 100644 --- a/test/test1/hex0.hex0 +++ b/test/test1/hex0.hex0 @@ -52,7 +52,7 @@ FB 00 60 00 00 00 00 00 ## e_entry Address of the entry point ## Program Header table 01 00 00 00 ## p_type -06 00 00 00 ## Flags +07 00 00 00 ## ph_flags: PF-X|PF-W|PF-R = 7 00 00 00 00 00 00 00 00 ## p_offset 00 00 60 00 00 00 00 00 ## p_vaddr 00 00 00 00 00 00 00 00 ## Undefined diff --git a/test/test1/hex1.hex0 b/test/test1/hex1.hex0 index a0aa3bc..1c6e0bf 100644 --- a/test/test1/hex1.hex0 +++ b/test/test1/hex1.hex0 @@ -38,7 +38,7 @@ ## Program Header table 01 00 00 00 # p_type -06 00 00 00 # Flags +07 00 00 00 # ph_flags: PF-X|PF-W|PF-R = 7 00 00 00 00 00 00 00 00 # p_offset 00 00 60 00 00 00 00 00 # p_vaddr 00 00 00 00 00 00 00 00 # Undefined diff --git a/test/test1/proof1.answer b/test/test1/proof1.answer index 7d3bb85..8c441ba 100644 --- a/test/test1/proof1.answer +++ b/test/test1/proof1.answer @@ -1 +1 @@ -4379770c34e718157f856d938f870ad8179b268e5454f9ff272aad4e43265149 test/test1/proof1 +d1172d0456de0ae4d05705fc7d81c424f4a277b7725d449829322ce07224bebf test/test1/proof1 diff --git a/test/test1/proof2.answer b/test/test1/proof2.answer index 2440710..6edd102 100644 --- a/test/test1/proof2.answer +++ b/test/test1/proof2.answer @@ -1 +1 @@ -5ac7c9c6671709682e06153310c112df5b9352af6f6fef93a3370566d28a9a90 test/test1/proof2 +e6b14d3e5935e52a49beff99b766dcd7c842ae2a8d76f4d4c8b10c2d6d146181 test/test1/proof2 diff --git a/test/test2/hex0.hex0 b/test/test2/hex0.hex0 index 126f909..6697221 100644 --- a/test/test2/hex0.hex0 +++ b/test/test2/hex0.hex0 @@ -42,7 +42,7 @@ FB 00 60 00 00 00 00 00 ## e_entry Address of the entry point ## Program Header table 01 00 00 00 ## p_type -06 00 00 00 ## Flags +07 00 00 00 ## ph_flags: PF-X|PF-W|PF-R = 7 00 00 00 00 00 00 00 00 ## p_offset 00 00 60 00 00 00 00 00 ## p_vaddr 00 00 00 00 00 00 00 00 ## Undefined ^ permalink raw reply related [flat|nested] 6+ messages in thread
* bug#49515: [core-updates] mescc-tools tests fail 2021-07-18 21:04 ` Ludovic Courtès 2021-07-18 21:08 ` Ludovic Courtès @ 2021-07-19 4:49 ` Jan Nieuwenhuizen 2021-07-26 11:40 ` Ludovic Courtès 1 sibling, 1 reply; 6+ messages in thread From: Jan Nieuwenhuizen @ 2021-07-19 4:49 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 49515 Ludovic Courtès writes: Hello, > Ludovic Courtès <ludo@gnu.org> skribis: > >> On commit 9b4c3c675c05870e5983c21ce4ff944e0b0bc2fa of ‘core-updates’, >> mescc-tools fails tests, with generated binaries segfaulting: >> >> $ ./pre-inst-env guix build mescc-tools >> >> […] >> >> + . ./sha256.sh >> ++ set -ex >> ++ ./bin/get_machine >> + ./bin/M1 -f test/test3/defs -f test/test3/lisp.s --BigEndian --architecture knight-native -o test/test3/hold >> + '[' amd64 = amd64 ']' >> + ./test/results/test1-binary >> + ./bin/hex2 -f elf_headers/elf32.hex2 -f test/test2/hold --LittleEndian --architecture x86 --BaseAddress 0x8048000 -o test/results/test2-binary --exec_enable >> test/test1/hello.sh: line 37: 125 Segmentation fault ./test/results/test1-binary < test/test1/hex0.hex0 > test/test1/proof1 > > [...] How weird! I wonder what changed... >> builder for `/gnu/store/lir8pmc63k1bcj4ml9gsx1769aw9ndj2-mescc-tools-0.7.0.drv' failed with exit code 1 > > I found that this upstream commit, which made it in version 1.1.0, fixes > the segfault: > > commit e633669dfdf16f503a7d740b9058e343536533b4 > Author: nimaje <nimaje@bootstrappable.irc_channel> > Date: Thu Oct 15 19:12:18 2020 -0400 > > Fix ELF headers to be more well behaved [..] > Should we upgrade instead? If we do, what’s the potential for breakage? > Should ‘mes-rb5’ be kept on an older version? We could try that, I really can't tell if upgrading to 1.1.0 creates a different mes binary. Greetings, Janneke -- Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#49515: [core-updates] mescc-tools tests fail 2021-07-19 4:49 ` Jan Nieuwenhuizen @ 2021-07-26 11:40 ` Ludovic Courtès 2021-07-26 13:43 ` Jan Nieuwenhuizen 0 siblings, 1 reply; 6+ messages in thread From: Ludovic Courtès @ 2021-07-26 11:40 UTC (permalink / raw) To: Jan Nieuwenhuizen; +Cc: 49515 Hi Janneke! Jan Nieuwenhuizen <janneke@gnu.org> skribis: >> Ludovic Courtès <ludo@gnu.org> skribis: >> >>> On commit 9b4c3c675c05870e5983c21ce4ff944e0b0bc2fa of ‘core-updates’, >>> mescc-tools fails tests, with generated binaries segfaulting: >>> >>> $ ./pre-inst-env guix build mescc-tools >>> >>> […] >>> >>> + . ./sha256.sh >>> ++ set -ex >>> ++ ./bin/get_machine >>> + ./bin/M1 -f test/test3/defs -f test/test3/lisp.s --BigEndian --architecture knight-native -o test/test3/hold >>> + '[' amd64 = amd64 ']' >>> + ./test/results/test1-binary >>> + ./bin/hex2 -f elf_headers/elf32.hex2 -f test/test2/hold --LittleEndian --architecture x86 --BaseAddress 0x8048000 -o test/results/test2-binary --exec_enable >>> test/test1/hello.sh: line 37: 125 Segmentation fault ./test/results/test1-binary < test/test1/hex0.hex0 > test/test1/proof1 [...] >> Should we upgrade instead? If we do, what’s the potential for breakage? >> Should ‘mes-rb5’ be kept on an older version? > > We could try that, I really can't tell if upgrading to 1.1.0 creates > a different mes binary. I took this route and everything went well, and we can now build ‘bootstrap-tarballs’ on x86_64-linux. I ended up doing additional changes: e2690a8eb2 gnu: mes-rb5: Remove. da32015db0 gnu: mes-minimal-stripped: Explicitly disallow references. 5510e1c483 gnu: mes: Remove 0.19. 81096caf7d gnu: mes: Switch to Guile 3.0. 114a9f1f80 gnu: mescc-tools: Update to 1.2.0. 0b9da8b5a2 gnu: m2-planet: Update to 1.8.0. 8b627a7701 gnu: mes-minimal: Remove unused variable. Removing ‘mes-rb5’ was a bit disheartening but I guess it’d have to be updated to the current tool versions. I removed Mes 0.19 because it failed to build with Guile 3.0 and didn’t appear to be needed any longer. Let me know if you think I did anything wrong! Thanks, Ludo’. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#49515: [core-updates] mescc-tools tests fail 2021-07-26 11:40 ` Ludovic Courtès @ 2021-07-26 13:43 ` Jan Nieuwenhuizen 0 siblings, 0 replies; 6+ messages in thread From: Jan Nieuwenhuizen @ 2021-07-26 13:43 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 49515 Ludovic Courtès writes: Hi Ludo! > Jan Nieuwenhuizen <janneke@gnu.org> skribis: > >>> Should we upgrade instead? If we do, what’s the potential for breakage? >>> Should ‘mes-rb5’ be kept on an older version? >> >> We could try that, I really can't tell if upgrading to 1.1.0 creates >> a different mes binary. > > I took this route and everything went well, and we can now build > ‘bootstrap-tarballs’ on x86_64-linux. I ended up doing additional > changes: > > e2690a8eb2 gnu: mes-rb5: Remove. > da32015db0 gnu: mes-minimal-stripped: Explicitly disallow references. > 5510e1c483 gnu: mes: Remove 0.19. > 81096caf7d gnu: mes: Switch to Guile 3.0. > 114a9f1f80 gnu: mescc-tools: Update to 1.2.0. > 0b9da8b5a2 gnu: m2-planet: Update to 1.8.0. > 8b627a7701 gnu: mes-minimal: Remove unused variable. > Removing ‘mes-rb5’ was a bit disheartening but I guess it’d have to be > updated to the current tool versions. Yeah, a bit sad but OK I guess. > I removed Mes 0.19 because it failed to build with Guile 3.0 and didn’t > appear to be needed any longer. > > Let me know if you think I did anything wrong! LGTM! Greetings, Janneke -- Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-07-26 13:45 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-07-10 23:56 bug#49515: [core-updates] mescc-tools tests fail Ludovic Courtès 2021-07-18 21:04 ` Ludovic Courtès 2021-07-18 21:08 ` Ludovic Courtès 2021-07-19 4:49 ` Jan Nieuwenhuizen 2021-07-26 11:40 ` Ludovic Courtès 2021-07-26 13:43 ` Jan Nieuwenhuizen
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).