bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 4/4] Add cpu_number and cpuboot


From: Flávio Cruz
Subject: Re: [PATCH 4/4] Add cpu_number and cpuboot
Date: Wed, 25 Jan 2023 01:54:35 -0500



On Wed, Jan 25, 2023 at 1:34 AM Jessica Clarke <jrtc27@jrtc27.com> wrote:
On 25 Jan 2023, at 06:27, Flávio Cruz <flaviocruz@gmail.com> wrote:
>> On Tue, Jan 24, 2023 at 2:54 AM Samuel Thibault <samuel.thibault@gnu.org> wrote:
>> Flávio Cruz, le mar. 24 janv. 2023 01:15:15 -0500, a ecrit:
>> >     +       int kernel_id;
>> >     +       unsigned long flags;
>> >     +
>> >     +       cpu_intr_save(&flags);
>> >     +
>> >     +       kernel_id = apic_get_cpu_kernel_id(apic_get_current_cpu());
>> >     +
>> >     +       cpu_intr_restore(flags);
>> >     +
>> >     +       return kernel_id;
>> >
>> >
>> > Might be unrelated to this change, but will this be portable for x86_64? It
>> > seems we either should use uint32_t to store EFLAGS or use pushfq/popfq to get
>> > RFLAGS instead.
>>
>> cpu_get_eflags will already use pushfq/popfq, won't it? (since it takes
>> the unsigned long output parameter.
>
> I tried it in compiler explorer and it shows we have to use pushfq explicitly: https://godbolt.org/z/MYjPaEh31

Not sure what you’re trying to show? pushf assembles to the same thing as pushfq.

I think you are right - just looked at the objdump output. Sorry for the noise


Jess

>> Samuel


reply via email to

[Prev in Thread] Current Thread [Next in Thread]