From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <kernelnewbies-bounces@kernelnewbies.org>
Received: from mail-lj1-x244.google.com ([2a00:1450:4864:20::244])
 by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128)
 (Exim 4.91) (envelope-from <cartercheng@gmail.com>)
 id 1gMFKH-0005ld-7b
 for kernelnewbies@kernelnewbies.org; Mon, 12 Nov 2018 11:44:37 -0500
Received: by mail-lj1-x244.google.com with SMTP id q186-v6so8206786ljb.5
 for <kernelnewbies@kernelnewbies.org>; Mon, 12 Nov 2018 08:44:36 -0800 (PST)
MIME-Version: 1.0
References: <CALS6=qWC-P24t-tgmxUNMesoYxqxLqK8Ef4-v=iLtYcmWTBwEw@mail.gmail.com>
 <CADFy_4HaGzY3Up279jP13RrJUn6cPuy7S5hk967N3_b57V+GhQ@mail.gmail.com>
 <CALS6=qWeafWvH+HZG=W3ojv8XabS=znXYzuoGYh67htnvQGnfw@mail.gmail.com>
 <96662.1542006572@turing-police.cc.vt.edu>
In-Reply-To: <96662.1542006572@turing-police.cc.vt.edu>
From: Carter Cheng <cartercheng@gmail.com>
Date: Tue, 13 Nov 2018 00:43:20 +0800
Message-ID:
 <CALS6=qX-X8E3DnnVsxyJXCQ_Mbee1ZTyON-2uJ2_5mvpY93XMg@mail.gmail.com>
Subject: Re: function stack frames in the kernel
To: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Cc: Augusto Caringi <augustocaringi@gmail.com>, kernelnewbies@kernelnewbies.org
List-Id: Learn about the Linux kernel <kernelnewbies.kernelnewbies.org>
List-Unsubscribe: <https://lists.kernelnewbies.org/mailman/options/kernelnewbies>,
 <mailto:kernelnewbies-request@kernelnewbies.org?subject=unsubscribe>
List-Archive: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/>
List-Post: <mailto:kernelnewbies@kernelnewbies.org>
List-Help: <mailto:kernelnewbies-request@kernelnewbies.org?subject=help>
List-Subscribe: <https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies>,
 <mailto:kernelnewbies-request@kernelnewbies.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4756645318064297893=="
Errors-To: kernelnewbies-bounces@kernelnewbies.org
Message-ID: <20181112164320.G9AwUmhLX0PCjARh1VEy5tg68valhqj2ij5UO8jR0ig@z>

--===============4756645318064297893==
Content-Type: multipart/alternative; boundary="000000000000cf6ee2057a7a66e4"

--000000000000cf6ee2057a7a66e4
Content-Type: text/plain; charset="UTF-8"

Thanks for the clarification.

On Mon, Nov 12, 2018 at 3:09 PM <valdis.kletnieks@vt.edu> wrote:

> On Mon, 12 Nov 2018 02:00:02 +0800, Carter Cheng said:
> > Thanks for the reply but the link doesn't quite answer the question. I am
> > wondering how the pointer is handled so that there is one per thread by
> the
> > compiler. I perhaps was under the perhaps mistaken impression that the
> > stack pointer frame pointer management inside the compiler makes certain
> > assumptions in user space- but i am unsure how this applies to kernel
> space.
>
> For regular function calls, a kernel stack works exactly the same as a
> function
> stack in userspace (remember, it's the same compiler, and other tools like
> the
> linker and gdb need to be able to understand function calls).
>
> Where things are different are what happens if an interrupt or a call to
> schedule() or enter/exit the kernel (or a few other similar situations I
> can't
> remember at 2AM) causes a different thread to start running - for those
> cases,
> there's architecture-dependent shim code (usually involving at least a bit
> of
> assembler) to do the register swapping needed.
>
>

--000000000000cf6ee2057a7a66e4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for the clarification.<br></div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr">On Mon, Nov 12, 2018 at 3:09 PM &lt;<a href=3D=
"mailto:valdis.kletnieks@vt.edu">valdis.kletnieks@vt.edu</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">On Mon, 12 Nov 2018 02:00:02 +0800, Ca=
rter Cheng said:<br>
&gt; Thanks for the reply but the link doesn&#39;t quite answer the questio=
n. I am<br>
&gt; wondering how the pointer is handled so that there is one per thread b=
y the<br>
&gt; compiler. I perhaps was under the perhaps mistaken impression that the=
<br>
&gt; stack pointer frame pointer management inside the compiler makes certa=
in<br>
&gt; assumptions in user space- but i am unsure how this applies to kernel =
space.<br>
<br>
For regular function calls, a kernel stack works exactly the same as a func=
tion<br>
stack in userspace (remember, it&#39;s the same compiler, and other tools l=
ike the<br>
linker and gdb need to be able to understand function calls).<br>
<br>
Where things are different are what happens if an interrupt or a call to<br=
>
schedule() or enter/exit the kernel (or a few other similar situations I ca=
n&#39;t<br>
remember at 2AM) causes a different thread to start running - for those cas=
es,<br>
there&#39;s architecture-dependent shim code (usually involving at least a =
bit of<br>
assembler) to do the register swapping needed.<br>
<br>
</blockquote></div>

--000000000000cf6ee2057a7a66e4--


--===============4756645318064297893==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

--===============4756645318064297893==--