From nobody Fri Feb 02 06:11:30 2024 X-Original-To: freebsd-riscv@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TR55D1SXQz59WM2 for ; Fri, 2 Feb 2024 06:11:44 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TR55C6570z4VtR for ; Fri, 2 Feb 2024 06:11:43 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-40fb804e4deso14959205e9.0 for ; Thu, 01 Feb 2024 22:11:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706854301; x=1707459101; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GHN31K4YQjC4cCGp+NkVzUjymXI/bpApqhFM/8QVBgI=; b=nvzI8//LIXDyWhkjXA16GvpGBf3g7NXNQMNUaGgRRXvEGVqKmsl9BwR51etyvaKiME 7IHmVkzqcDR9PbL88J7C8n+8dtBXOEgiS05lypVFQCC0+HqryrFk/BNZPL0qjGb3SZyq BHImr8kgCwwqL/vu0TuITySUpltxS6GMTWqmPz/ZJ+LkRYuXgzgOuVJBGl46ZGUwyi/B Y+FriJqF5+2ymeKhHQB8EL5xkLnw0lzoZQ6bdgREoClScy5xiqaEz1+chzZF5MmNds+b spKlJM0/rZst051zhe8mfyrDi5/yctKVjobRBpU7FslGeyrtm8KPxU1G4jTYj2vDlls3 EM0A== X-Gm-Message-State: AOJu0Ywe8SBZ5qsFBmHoemo2ioWVW5GyF1dmGaIA0ZN/CZjLiQ6YnQjK BcWYhRd09jAM3bWkrNAVv4mYf1wo6Td0dSG68eu5Rr/RP68P/TseV2/kEnOqfh02l8dm53whC0W 3 X-Google-Smtp-Source: AGHT+IFiPXdcx6Qj/1e+TOv5VqA0DuzeD5btluTzZgr4ILJkcx7IeftjR4oERVnK9z7JOK+tuwOs1A== X-Received: by 2002:a05:600c:511e:b0:40f:b783:ad2e with SMTP id o30-20020a05600c511e00b0040fb783ad2emr3738369wms.21.1706854301541; Thu, 01 Feb 2024 22:11:41 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCWXPHEUwXESCp+hO/fwafPavIeRa/0Oa0BOU79nlkoMdp56sgkhznFfw5MNxVJlR4FgCg8IywoaUFwfLQFagdbKba4= Received: from smtpclient.apple ([131.111.5.246]) by smtp.gmail.com with ESMTPSA id fa6-20020a05600c518600b0040efb445698sm6360990wmb.5.2024.02.01.22.11.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Feb 2024 22:11:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 List-Id: FreeBSD on the RISC-V instruction set architecture List-Archive: https://lists.freebsd.org/archives/freebsd-riscv List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-riscv@freebsd.org X-BeenThere: freebsd-riscv@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: A little bit wondering about how a syscall works From: Jessica Clarke In-Reply-To: Date: Fri, 2 Feb 2024 06:11:30 +0000 Cc: freebsd-riscv , Mitchell Horne Content-Transfer-Encoding: quoted-printable Message-Id: <1D587966-19FD-47C9-B362-B55068665C2E@freebsd.org> References: <9204b5c5-63bc-4c29-af19-1f1bb85f74e8@Spark> <8f66f3ed-2a49-4ebc-89eb-66c53e6d22bb@Spark> <9bfbdbe2-ff30-4c2f-abf3-2763aa433107@freebsd.org> <8867a483-7e92-4579-9236-32b4a704713e@Spark> <51285fdf-dbcf-4d71-82cb-f49353db95cd@freebsd.org> To: Lin Lee X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Rspamd-Queue-Id: 4TR55C6570z4VtR X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] On 2 Feb 2024, at 05:49, Lin Lee wrote: >=20 > Hi, >=20 > But what I see in = https://github.com/freebsd/freebsd-src/blob/main/sys/kern/subr_syscall.c = is(after removing some condition branching): >=20 > 77 error =3D (p->p_sysent->sv_fetch_syscall_args)(td); > 78 se =3D sa->callp; > 156 error =3D (se->sy_call)(td, sa->args); >=20 > It seems that `sv_set_syscall_retval hook` is called earlier than = syscall is executed. And sv_set_syscall_retval is called on line 204 after all of that. What=E2=80=99s making you think otherwise? Jess > Thank you so much for your replying.=20 >=20 > Best Regards,=20 > Lin Lee > On Feb 2, 2024 at 12:19 AM +0800, Mitchell Horne , = wrote: >> On 2/1/24 00:47, Lin Lee wrote: >>> Hi, >>>=20 >>> So, if I understand correctly, >>>=20 >>> Each thread's sv_fetch_syscall_args hook function is initialized as >>> cpu_fetch_syscall_args(), >>>=20 >>> And when it enter syscallenter, it first use `error =3D >>> (p->p_sysent->sv_fetch_syscall_args)(td);` to read the system call >>> number, then use `error =3D (se->sy_call)(td, sa->args)` to execute = the >>> system call. >>>=20 >>> Do I understand corrected? >>>=20 >>=20 >> That's right. >>=20 >>> Thank you very much. >>>=20 >>> Best Regards, >>> Lin Lee >>> On Feb 1, 2024 at 12:27 AM +0800, Mitchell Horne = , >>> wrote: >>>> On 1/31/24 01:03, Lin Lee wrote: >>>>> Hello Mitchell, >>>>>=20 >>>>> Thank you for your kindly responding. >>>>>=20 >>>>> Now I have still a question, when does the function >>>>> cpu_fetch_syscall_args be called? >>>>>=20 >>>>> As the previous letter mentions, I traced the code and entered the >>>>> elf_machdep.c. >>>>>=20 >>>>> I have no idea if there are something to do between elf_machdep.c = and >>>>> system calll. >>>>>=20 >>>>=20 >>>> The short answer is yes, it is related. In syscallenter() we have: >>>>=20 >>>> error =3D (p->p_sysent->sv_fetch_syscall_args)(td); >>>>=20 >>>> And as you saw, the sv_fetch_syscall_args hook is set to >>>> cpu_fetch_syscall_args() for elf64_freebsd_sysvec. Similarly, there = is >>>> an sv_set_syscall_retval hook, called by syscallret() when we are = done >>>> executing the system call. >>>>=20 >>=20 >> One correction: the sv_set_syscall_retval hook is actually called at = the >> very end of syscallenter(), after the execution of the syscall has >> completed. >>=20 >>>> Each process 'p' has a corresponding sysentvec (p_sysent). On the >>>> riscv architecture there is currently only one registered = systentvec, >>>> elf64_freebsd_sysvec, because we can only execute 64-bit FreeBSD = ELF >>>> binaries on this platform. >>>>=20 >>>> By contrast, on amd64 there are several registered sysentvecs. This >>>> allows it to execute, for example, 32-bit FreeBSD ELF binaries, or >>>> 64-bit Linux ELF binaries. The sysentvec enables different handling >>>> for these different types of executables, e.g. the system call = table >>>> is different for Linux processes (.sv_table =3D linux_sysent). >>>>=20 >>>> You will see also that Linux processes have a different function = for >>>> sv_fetch_syscall_args, take a look in = sys/amd64/linux/linux_sysvec.c. >>>>=20 >>>> Mitchell >>>>=20 >>>>> If not, when(how) the cpu_fetch_syscall_args is called? >>>>>=20 >>>>> Thank you very much. >>>>>=20 >>>>> Best Regards, >>>>> Lin Lee >>>>> On Jan 31, 2024 at 1:17 AM +0800, Mitchell Horne = , >>>>> wrote: >>>>>>=20 >>>>>> Mitchell >>>>=20 >>=20