Re: [PATCH 2/4] target/arm: Move cortex-m related functions to new file v7m.c

[Thomas Huth]

On 24/09/2019 13.02, Auger Eric wrote:
> Hi Thomas,
> 
> On 9/23/19 8:09 PM, Thomas Huth wrote:
>> On 23/09/2019 16.31, Auger Eric wrote:
>>> Hi Thomas,
>>>
>>> On 9/21/19 5:04 PM, Thomas Huth wrote:
>>>> We are going to make CONFIG_ARM_V7M optional, so the related cortex-m
>>>> CPUs should only be created if the switch is enabled. This can best
>>>> be done if the code resides in a separate file, thus move the related
>>>> functions to a new file v7m.c which only gets compiled if CONFIG_ARM_V7M
>>>> is enabled.
>>>>
>>>> Signed-off-by: Thomas Huth <address@hidden>
>>>> ---
>>>>  target/arm/Makefile.objs |   1 +
>>>>  target/arm/cpu.c         | 146 -----------------------------
>>>>  target/arm/v7m.c         | 193 +++++++++++++++++++++++++++++++++++++++
>>>>  3 files changed, 194 insertions(+), 146 deletions(-)
>>>>  create mode 100644 target/arm/v7m.c
>> [...]
>>>> diff --git a/target/arm/v7m.c b/target/arm/v7m.c
>>>> new file mode 100644
>>>> index 0000000000..505043febe
>>>> --- /dev/null
>>>> +++ b/target/arm/v7m.c
>>>> @@ -0,0 +1,193 @@
>>>> +/*
>>>> + * ARM v7m helpers.
>>>> + *
>>>> + * This code is licensed under the GNU GPL v2 or later.
>>>> + *
>>>> + * SPDX-License-Identifier: GPL-2.0-or-later
>>>> + */
>>>> +
>>>> +#include "qemu/osdep.h"
>>>> +#include "qemu/qemu-print.h"
>>>> +#include "qemu-common.h"
>>>> +#include "target/arm/idau.h"
>>>> +#include "qemu/module.h"
>>>> +#include "qapi/error.h"
>>>> +#include "qapi/visitor.h"
>>>> +#include "cpu.h"
>>>> +#include "internals.h"
>>>> +#include "exec/exec-all.h"
>>>> +#include "hw/qdev-properties.h"
>>>> +#if !defined(CONFIG_USER_ONLY)
>>>> +#include "hw/loader.h"
>>>> +#include "hw/boards.h"
>>>> +#endif
>>>> +#include "sysemu/sysemu.h"
>>>> +#include "sysemu/tcg.h"
>>>> +#include "sysemu/hw_accel.h"
>>>> +#include "disas/capstone.h"
>>>> +#include "fpu/softfloat.h"
>>>
>>> I guess some of those headers are not needed.
>>
>> Yeah, I just copy-n-pasted from the source file ... I'll check what can
>> be omitted (if this patch series has a chance at all...)
>>
>>>> +
>>>> +#if !defined(CONFIG_USER_ONLY) || !defined(TARGET_AARCH64)
>>>> +
>>>> +static bool arm_v7m_cpu_exec_interrupt(CPUState *cs, int 
>>>> interrupt_request)
>>>> +{
>>>> +    CPUClass *cc = CPU_GET_CLASS(cs);
>>>> +    ARMCPU *cpu = ARM_CPU(cs);
>>>> +    CPUARMState *env = &cpu->env;
>>>> +    bool ret = false;
>>>> +
>>>> +    /*
>>>> +     * ARMv7-M interrupt masking works differently than -A or -R.
>>>> +     * There is no FIQ/IRQ distinction. Instead of I and F bits
>>>> +     * masking FIQ and IRQ interrupts, an exception is taken only
>>>> +     * if it is higher priority than the current execution priority
>>>> +     * (which depends on state like BASEPRI, FAULTMASK and the
>>>> +     * currently active exception).
>>>> +     */
>>>> +    if (interrupt_request & CPU_INTERRUPT_HARD
>>>> +        && (armv7m_nvic_can_take_pending_exception(env->nvic))) {
>>>
>>> so what is the status wrt m_helper.c which stays unconditionally
>>> compiled. m_helper functions seem to called from target/arm/translate.c
>>> mostly. Have you abandoned the stub idea. It may be confusing to have 2
>>> different helper files. At least a comment explaining where a new helper
>>> shall go may be useful.
>>
>> All the HELPER() functions should definitely stay in m_helper.c. They
>> are required for linking. Or do you prefer a stub file instead? Then we
>> could maybe make the whole m_helper.c conditional in the Makefile.objs
>> instead.
> 
> I was simply referring to your previous approach:
> 
> Applying [Qemu-devel] [RFC PATCH 3/3] target/arm: Make m_helper.c
> optional via CONFIG_ARM_V7M seems to fix the issue
> https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg00333.html
> 
> It seems to work fine as it removes the call to armv7m_nvic.c functions
> so no need to move the interrupt controller code?

Yes, but then we either need stubs in a separate file, or have to put
lots of #ifdefs into translate.c ... none of those solutions seem to be
really perfect :-(
Anyway, Philippe is currently respinning his series (I think), so I'll
postpone my work now to avoid to interfere with him.

 Thomas