Hi!
On Fri, 2021-05-14 16:11:19 -0400, Christos Zoulas <christos%zoulas.com@localhost> wrote:
> Save the failed build and compare it with a successful one (file sizes).
> See which files are different and where. Something must be broken.
So here's another round of builds. I bind-mounted some scratch space
/short and
/loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong
and started builds in these two directories.
Ignoring some messages containing timestamps, different order of
file names and mktemp() based filenames, I have see that creating
ctags fails (though I thought Linux had dynamically allocated process
argument space?!):
However, coming back to the ramdisk content (I guess this is it):
root@spock:/# du -ks /{short,loo*}/obj/distrib/sun2/ramdisk/work
572 /short/obj/distrib/sun2/ramdisk/work
584 /loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong/obj/distrib/sun2/ramdisk/work
root@spock:/short/obj/tooldir.Linux-5.10.0-3-amd64-x86_64/bin# ./m68010--netbsdelf-size /{short,loo*}/obj/distrib/sun2/ramdisk/work/bin/cat
text data bss dec hex filename
513036 9200 46780 569016 8aeb8 /short/obj/distrib/sun2/ramdisk/work/bin/cat
526720 9200 46780 582700 8e42c /loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong/obj/distrib/sun2/ramdisk/work/bin/cat
However, m68k-readelf's (from above tooldir) output diff's like this:
root@spock:/short/obj/tooldir.Linux-5.10.0-3-amd64-x86_64/bin# diff -u /tmp/readelf-t-*
--- /tmp/readelf-t-long 2021-05-16 21:30:31.634520067 +0200
+++ /tmp/readelf-t-short 2021-05-16 21:30:39.894380367 +0200
@@ -1,5 +1,5 @@
-File: /loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong/obj/distrib/sun2/ramdisk/work/bin/cat
-There are 13 section headers, starting at offset 0x84458:
+File: /short/obj/distrib/sun2/ramdisk/work/bin/cat
+There are 13 section headers, starting at offset 0x80458:
Section Headers:
[Nr] Name
@@ -21,26 +21,26 @@
PROGBITS 0006ac32 068c32 000008 00 0 0 2
[00000006]: ALLOC, EXEC
[ 5] .rodata
- PROGBITS 0006ac40 068c40 017dee 00 0 0 8
+ PROGBITS 0006ac40 068c40 01487a 00 0 0 8
[00000002]: ALLOC
[ 6] .init_array
- INIT_ARRAY 00094000 082000 000018 04 0 0 4
+ INIT_ARRAY 00090000 07e000 000018 04 0 0 4
[00000003]: WRITE, ALLOC
[ 7] .ctors
- PROGBITS 00094018 082018 000008 00 0 0 4
+ PROGBITS 00090018 07e018 000008 00 0 0 4
[00000003]: WRITE, ALLOC
[ 8] .dtors
- PROGBITS 00094020 082020 000008 00 0 0 4
+ PROGBITS 00090020 07e020 000008 00 0 0 4
[00000003]: WRITE, ALLOC
[ 9] .jcr
- PROGBITS 00094028 082028 000004 00 0 0 4
+ PROGBITS 00090028 07e028 000004 00 0 0 4
[00000003]: WRITE, ALLOC
[10] .data
- PROGBITS 00094030 082030 0023c4 00 0 0 8
+ PROGBITS 00090030 07e030 0023c4 00 0 0 8
[00000003]: WRITE, ALLOC
[11] .bss
- NOBITS 000963f8 0843f4 00b6bc 00 0 0 8
+ NOBITS 000923f8 0803f4 00b6bc 00 0 0 8
[00000003]: WRITE, ALLOC
[12] .shstrtab
- STRTAB 00000000 0843f4 000062 00 0 0 1
+ STRTAB 00000000 0803f4 000062 00 0 0 1
[00000000]:
So it's actually .rodata that's being sized up here. Dumping .rodata
(readelf -x .rodata) actually reveals many occurrecnces of the
looooong dirname and comparing to sources, I guess the "culprit"
pulling in the source filenames (with full path) is _DIAGASSERT() as
used from within NetBSD's libc. These two builds were, however, done
without the patch (by Izumi Tsutsui) adding "DBG+= -DNDEBUG" to
distrib/sun2/miniroot/Makefile. If libc is built with this DBG flag,
that might actually help. Will give this a try next.
For reference, I'll attach the two multi-call binaries.
Thanks,
Jan-Benedict
--
Attachment:
multicall-long
Description: Binary data
Attachment:
multicall-short
Description: Binary data
Attachment:
signature.asc
Description: PGP signature