Skip to content

runtime: several FreeBSD syscall wrappers seem to mishandle errors #43106

@benesch

Description

@benesch

I'm in the process of porting gccgo to FreeBSD and noticed something sketchy about some of the FreeBSD-specific syscall wrappers in the runtime package. Consider sys_umtx_op for example:

TEXT runtime·sys_umtx_op(SB),NOSPLIT,$0
MOVQ addr+0(FP), DI
MOVL mode+8(FP), SI
MOVL val+12(FP), DX
MOVQ uaddr1+16(FP), R10
MOVQ ut+24(FP), R8
MOVL $454, AX
SYSCALL
MOVL AX, ret+32(FP)
RET

The caller of this function expects negative values to be errors and positive values to be successes:

ret := sys_umtx_op(addr, _UMTX_OP_WAIT_UINT_PRIVATE, val, unsafe.Sizeof(*utp), utp)
if ret >= 0 || ret == -_EINTR {
return
}

But sys_umtx_op returns the result of the syscall (the AX register) directly, and according to the FreeBSD calling convention, the carry flag indicates whether AX contains an error code or successful return code, not the sign of the result. Most of the other syscalls in the package seem to get this right (anything that contains a JCC instruction after SYSCALL, roughly speaking, looks right to me), but a few others seem broken in the same way, like thr_new and pipe2.

#10052 seems to be some prior art on this subject. As a result a number of these syscall wrappers were fixed to inspect the carry flag, but not all of them.

Clearly in practice this doesn't seem to matter much, but probably worth fixing nonetheless.

Metadata

Metadata

Assignees

No one assigned

    Labels

    FrozenDueToAgeNeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.help wanted

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions