Page MenuHomeFreeBSD

csu: Ensure that errno is zero at program startup time
ClosedPublic

Authored by markj on Jun 23 2025, 11:59 PM.
Tags
None
Referenced Files
F132274527: D50998.id157492.diff
Wed, Oct 15, 10:13 AM
F132274520: D50998.id157490.diff
Wed, Oct 15, 10:13 AM
F132274516: D50998.id157486.diff
Wed, Oct 15, 10:13 AM
F132274515: D50998.id.diff
Wed, Oct 15, 10:13 AM
Unknown Object (File)
Tue, Oct 14, 11:28 PM
Unknown Object (File)
Mon, Sep 29, 10:44 PM
Unknown Object (File)
Sat, Sep 27, 10:36 PM
Unknown Object (File)
Thu, Sep 25, 9:58 AM
Subscribers

Details

Summary
A dummy application which prints errno as its first action reveals that
errno is non-zero in at least two cases: the application is linked with
libthr.so, because the thr_wake(-1) call in _thr_rtld_init() sets errno
= ESRCH, and second, the application is statically linked with libthr.a,
since libc's uexterr_ctr() runs after the exterrctl(EXTERRCTL_ENABLE)
call in init_main_thread(), so the second exterrctl() call returns EBUSY
(since it does not specify EXTERRCTLF_FORCE.

Just zero errno immediately before program startup.  Or, maybe we should
be more careful and clear errno in the precise spots where errors can
occur?

Reported by:	Greg Becker

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 65036
Build 61919: arc lint + arc unit

Event Timeline

markj edited the summary of this revision. (Show Details)

Also see D50997.

Note that any constructor could leave errno non-zero, libc and libthr are not more guilty than arbitrary user code there.

From this PoV, the proper test for the issue should include some code like this:

static void f(void) __attribute__((constructor));
static void
f(void)
{
   errno = 11;
}
This revision is now accepted and ready to land.Jun 24 2025, 12:48 AM
In D50998#1163935, @kib wrote:

Also see D50997.

You posted first and your version has a nice comment, so please go ahead and I'll commit the updated tests separately.

Set errno from a constructor.

This revision now requires review to proceed.Jun 24 2025, 1:09 AM
This revision is now accepted and ready to land.Jun 24 2025, 1:14 AM