[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 7/9] hurd: Generalize init-first.c to support x86_64
From: |
Samuel Thibault |
Subject: |
Re: [RFC PATCH 7/9] hurd: Generalize init-first.c to support x86_64 |
Date: |
Mon, 20 Feb 2023 18:31:08 +0100 |
User-agent: |
NeoMutt/20170609 (1.8.3) |
Sergey Bugaev, le lun. 20 févr. 2023 20:10:29 +0300, a ecrit:
> - the implementation does not seem to actually switch stacks (in fact,
> I have removed the unused switch_stacks function in the last commit)
> -- so the "gets called with the stack just as the application's entry
> point will see it" property may not be important anymore?
That's possible, yes.
> So my thinking goes, why don't we just hook into _dl_start, which
> already has this very pointer? And in fact, _dl_start calls
> _dl_sysdep_start, for which there is already a Hurd version. Can't we
> just call our logic from there, and not worry about the stack layout
> and overwriting return addresses?
Possibly, yes.
> That would work for the SHARED case; we also need to do something for
> the static case. In that case, we are invoked by static-start.S; do I
> understand it right that the argc/argv/whatever is still located
> on-stack even on x86_64 in this case, and not passed in registers
> according to the calling convention?
I don't know. But you can check on Linux, we'll probably want to use the
same ABI.
Samuel
[RFC PATCH 8/9 gnumach] Add i386_fsgs_base_state, Sergey Bugaev, 2023/02/18
[RFC PATCH 9/9] hurd, htl: Add some more x86_64-specific code, Sergey Bugaev, 2023/02/18