On Thu, May 15, 2025 at 06:28:42PM +1000, Jonathan Matthew wrote: > On Tue, May 13, 2025 at 07:55:03AM +0200, Otto Moerbeek wrote: > > On Mon, May 12, 2025 at 08:07:11PM +0200, Sebastien Marie wrote: > > > > > > I suppose the same could occurs with lld (untested for now). > > > > > > I confirm it is the same problem with lld. > > > > > > $ cd /usr/share/relink/kernel/GENERIC.MP > > > $ ld -T ld.script -X --warn-common -nopie -o /tmp/newbsd *.o && echo ok > > > > > > /tmp: write failed, file system is full > > > ok > > > $ ls -l /tmp/newbsd > > > -rwxr-xr-x 1 semarie wheel 236434608 May 12 20:05 /tmp/newbsd* > > > > > > And my dmesg has the following: > > > uvn_flush: obj=0xfffffd86e3311608, offset=0x16b0000. error during > > > pageout. > > > uvn_flush: WARNING: changes to page may be lost! > > > > So this code is using mmapped files for writing, which makes proper > > error handling extremely difficult or even impossible. Best bet is > > making sure enough space is available before starting. > > lld has a --no-mmap-output-file option that causes it to use plain write(2) > calls to generate the output file. Perhaps it'd be worth using that for > kernel linking and other stuff we relink at boot time? Maybe that should be the default. Having lld produce bad binaries but exit 0 is just very wrong. Not sure if this a problem that only manifests on OpenBSD since there is no unified buffer cache or if other systems would hit the same issue as well. As Otto mentioned detection IO errors when using mmap to write files is not trivial.
-- :wq Claudio
