Some variables with external linkage used in C code do not have
a visible declaration where they are defined. Providing such
declaration also resolves violations of MISRA C:2012 Rule 8.4.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
Changes in v2:
- make xenpf_lock static on ARM
- moved the declaration of cr4_pv32_mask to the appropriate file
---
xen/arch/arm/include/asm/setup.h | 3 +++
xen/arch/arm/include/asm/smp.h | 3 +++
xen/arch/arm/platform_hypercall.c | 2 +-
xen/arch/x86/cpu/mcheck/mce.c | 6 +++---
xen/arch/x86/include/asm/compat.h | 1 +
xen/arch/x86/include/asm/setup.h | 1 +
xen/arch/x86/irq.c | 2 +-
xen/common/symbols.c | 17 -----------------
xen/include/xen/symbols.h | 18 ++++++++++++++++++
9 files changed, 31 insertions(+), 22 deletions(-)
diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index b8866c20f462..8806a74b216d 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -183,9 +183,12 @@ int map_range_to_domain(const struct dt_device_node *dev,
extern lpae_t boot_pgtable[XEN_PT_LPAE_ENTRIES];
#ifdef CONFIG_ARM_64
+extern lpae_t boot_first[XEN_PT_LPAE_ENTRIES];
extern lpae_t boot_first_id[XEN_PT_LPAE_ENTRIES];
#endif
+extern lpae_t boot_second[XEN_PT_LPAE_ENTRIES];
extern lpae_t boot_second_id[XEN_PT_LPAE_ENTRIES];
+extern lpae_t boot_third[XEN_PT_LPAE_ENTRIES * XEN_NR_ENTRIES(2)];
extern lpae_t boot_third_id[XEN_PT_LPAE_ENTRIES];
/* Find where Xen will be residing at runtime and return a PT entry */
diff --git a/xen/arch/arm/include/asm/smp.h b/xen/arch/arm/include/asm/smp.h
index 4fabdf5310d8..28bf24a01d95 100644
--- a/xen/arch/arm/include/asm/smp.h
+++ b/xen/arch/arm/include/asm/smp.h
@@ -6,6 +6,9 @@
#include <asm/current.h>
#endif
+extern struct init_info init_data;
+extern unsigned long smp_up_cpu;
+
DECLARE_PER_CPU(cpumask_var_t, cpu_sibling_mask);
DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
diff --git a/xen/arch/arm/platform_hypercall.c b/xen/arch/arm/platform_hypercall.c
index 743687a30390..fde4bc3e5809 100644
--- a/xen/arch/arm/platform_hypercall.c
+++ b/xen/arch/arm/platform_hypercall.c
@@ -17,7 +17,7 @@
#include <asm/current.h>
#include <asm/event.h>
-DEFINE_SPINLOCK(xenpf_lock);
+static DEFINE_SPINLOCK(xenpf_lock);
long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
{
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 6141b7eb9cf1..e855f958030d 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1682,13 +1682,13 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
return ret;
}
-int mcinfo_dumpped;
+static int mcinfo_dumped;
static int cf_check x86_mcinfo_dump_panic(mctelem_cookie_t mctc)
{
struct mc_info *mcip = mctelem_dataptr(mctc);
x86_mcinfo_dump(mcip);
- mcinfo_dumpped++;
+ mcinfo_dumped++;
return 0;
}
@@ -1702,7 +1702,7 @@ static void mc_panic_dump(void)
for_each_online_cpu(cpu)
mctelem_process_deferred(cpu, x86_mcinfo_dump_panic,
mctelem_has_deferred_lmce(cpu));
- dprintk(XENLOG_ERR, "End dump mc_info, %x mcinfo dumped\n", mcinfo_dumpped);
+ dprintk(XENLOG_ERR, "End dump mc_info, %x mcinfo dumped\n", mcinfo_dumped);
}
void mc_panic(const char *s)
diff --git a/xen/arch/x86/include/asm/compat.h b/xen/arch/x86/include/asm/compat.h
index 818cad87db67..6f84f1571666 100644
--- a/xen/arch/x86/include/asm/compat.h
+++ b/xen/arch/x86/include/asm/compat.h
@@ -13,6 +13,7 @@ typedef unsigned long full_ptr_t;
struct domain;
#ifdef CONFIG_PV32
+extern unsigned long cr4_pv32_mask;
int switch_compat(struct domain *);
#else
#include <xen/errno.h>
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
index dfdd9e555149..6d22d3bd467a 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -13,6 +13,7 @@ extern char __2M_rwdata_start[], __2M_rwdata_end[];
extern unsigned long xenheap_initial_phys_start;
extern uint64_t boot_tsc_stamp;
+extern char cpu0_stack[STACK_SIZE];
extern void *stack_start;
void early_cpu_init(void);
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 6abfd8162120..604dba94b052 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -43,7 +43,7 @@ int __read_mostly opt_irq_vector_map = OPT_IRQ_VECTOR_MAP_DEFAULT;
static unsigned char __read_mostly irq_max_guests;
integer_param("irq-max-guests", irq_max_guests);
-vmask_t global_used_vector_map;
+static vmask_t global_used_vector_map;
struct irq_desc __read_mostly *irq_desc = NULL;
diff --git a/xen/common/symbols.c b/xen/common/symbols.c
index 691e61792506..7c3514c65f2e 100644
--- a/xen/common/symbols.c
+++ b/xen/common/symbols.c
@@ -21,23 +21,6 @@
#include <xen/guest_access.h>
#include <xen/errno.h>
-#ifdef SYMBOLS_ORIGIN
-extern const unsigned int symbols_offsets[];
-#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
-#else
-extern const unsigned long symbols_addresses[];
-#define symbols_address(n) symbols_addresses[n]
-#endif
-extern const unsigned int symbols_num_syms;
-extern const u8 symbols_names[];
-
-extern const struct symbol_offset symbols_sorted_offsets[];
-
-extern const u8 symbols_token_table[];
-extern const u16 symbols_token_index[];
-
-extern const unsigned int symbols_markers[];
-
/* expand a compressed symbol data into the resulting uncompressed string,
given the offset to where the symbol is in the compressed stream */
static unsigned int symbols_expand_symbol(unsigned int off, char *result)
diff --git a/xen/include/xen/symbols.h b/xen/include/xen/symbols.h
index 20bbb28ef226..92540409265e 100644
--- a/xen/include/xen/symbols.h
+++ b/xen/include/xen/symbols.h
@@ -33,4 +33,22 @@ struct symbol_offset {
uint32_t stream; /* .. in the compressed stream.*/
uint32_t addr; /* .. and in the fixed size address array. */
};
+
+#ifdef SYMBOLS_ORIGIN
+extern const unsigned int symbols_offsets[];
+#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
+#else
+extern const unsigned long symbols_addresses[];
+#define symbols_address(n) symbols_addresses[n]
+#endif
+extern const unsigned int symbols_num_syms;
+extern const u8 symbols_names[];
+
+extern const struct symbol_offset symbols_sorted_offsets[];
+
+extern const u8 symbols_token_table[];
+extern const u16 symbols_token_index[];
+
+extern const unsigned int symbols_markers[];
+
#endif /*_XEN_SYMBOLS_H*/
--
2.34.1On 09.10.2023 08:54, Nicola Vetrini wrote:
> Some variables with external linkage used in C code do not have
> a visible declaration where they are defined. Providing such
> declaration also resolves violations of MISRA C:2012 Rule 8.4.
>
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
This is a mix of different approaches to the same underlying issue. I
think respectively splitting would have helped.
> --- a/xen/arch/x86/include/asm/compat.h
> +++ b/xen/arch/x86/include/asm/compat.h
> @@ -13,6 +13,7 @@ typedef unsigned long full_ptr_t;
>
> struct domain;
> #ifdef CONFIG_PV32
> +extern unsigned long cr4_pv32_mask;
Why is this needed? Didn't we say declarations aren't needed when the
only consumer is assembly code? (I also wonder how this header is any
more "appropriate" - see the changelog entry - than about any other
one.)
> --- a/xen/arch/x86/include/asm/setup.h
> +++ b/xen/arch/x86/include/asm/setup.h
> @@ -13,6 +13,7 @@ extern char __2M_rwdata_start[], __2M_rwdata_end[];
> extern unsigned long xenheap_initial_phys_start;
> extern uint64_t boot_tsc_stamp;
>
> +extern char cpu0_stack[STACK_SIZE];
Same question here.
> --- a/xen/common/symbols.c
> +++ b/xen/common/symbols.c
> @@ -21,23 +21,6 @@
> #include <xen/guest_access.h>
> #include <xen/errno.h>
>
> -#ifdef SYMBOLS_ORIGIN
> -extern const unsigned int symbols_offsets[];
> -#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
> -#else
> -extern const unsigned long symbols_addresses[];
> -#define symbols_address(n) symbols_addresses[n]
> -#endif
> -extern const unsigned int symbols_num_syms;
> -extern const u8 symbols_names[];
> -
> -extern const struct symbol_offset symbols_sorted_offsets[];
> -
> -extern const u8 symbols_token_table[];
> -extern const u16 symbols_token_index[];
> -
> -extern const unsigned int symbols_markers[];
> -
> /* expand a compressed symbol data into the resulting uncompressed string,
> given the offset to where the symbol is in the compressed stream */
> static unsigned int symbols_expand_symbol(unsigned int off, char *result)
> --- a/xen/include/xen/symbols.h
> +++ b/xen/include/xen/symbols.h
> @@ -33,4 +33,22 @@ struct symbol_offset {
> uint32_t stream; /* .. in the compressed stream.*/
> uint32_t addr; /* .. and in the fixed size address array. */
> };
> +
> +#ifdef SYMBOLS_ORIGIN
> +extern const unsigned int symbols_offsets[];
> +#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
> +#else
> +extern const unsigned long symbols_addresses[];
> +#define symbols_address(n) symbols_addresses[n]
> +#endif
> +extern const unsigned int symbols_num_syms;
> +extern const u8 symbols_names[];
> +
> +extern const struct symbol_offset symbols_sorted_offsets[];
> +
> +extern const u8 symbols_token_table[];
> +extern const u16 symbols_token_index[];
> +
> +extern const unsigned int symbols_markers[];
> +
> #endif /*_XEN_SYMBOLS_H*/
This change is even less clear to me: The producer is assembly code,
and the consumer already had appropriate declarations. Why would we
want to increase the scope of their visibility?
Jan
On 16/10/2023 16:50, Jan Beulich wrote:
> On 09.10.2023 08:54, Nicola Vetrini wrote:
>> Some variables with external linkage used in C code do not have
>> a visible declaration where they are defined. Providing such
>> declaration also resolves violations of MISRA C:2012 Rule 8.4.
>>
>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>
> This is a mix of different approaches to the same underlying issue. I
> think respectively splitting would have helped.
>
>> --- a/xen/arch/x86/include/asm/compat.h
>> +++ b/xen/arch/x86/include/asm/compat.h
>> @@ -13,6 +13,7 @@ typedef unsigned long full_ptr_t;
>>
>> struct domain;
>> #ifdef CONFIG_PV32
>> +extern unsigned long cr4_pv32_mask;
>
> Why is this needed? Didn't we say declarations aren't needed when the
> only consumer is assembly code? (I also wonder how this header is any
> more "appropriate" - see the changelog entry - than about any other
> one.)
>
It was pointed out to me [1] that compat.h might be more appropriate
than setup.h
(probably because the asm code referencing it is under x86_64/compat).
Further, while it's true that this variable is used in asm, it's also
used in x86/setup.c, hence
the need for a declaration.
>> --- a/xen/arch/x86/include/asm/setup.h
>> +++ b/xen/arch/x86/include/asm/setup.h
>> @@ -13,6 +13,7 @@ extern char __2M_rwdata_start[], __2M_rwdata_end[];
>> extern unsigned long xenheap_initial_phys_start;
>> extern uint64_t boot_tsc_stamp;
>>
>> +extern char cpu0_stack[STACK_SIZE];
>
> Same question here.
>
This one is a bit more nuanced (I wouldn't oppose deviating this), but
there is indeed one use.
>> --- a/xen/common/symbols.c
>> +++ b/xen/common/symbols.c
>> @@ -21,23 +21,6 @@
>> #include <xen/guest_access.h>
>> #include <xen/errno.h>
>>
>> -#ifdef SYMBOLS_ORIGIN
>> -extern const unsigned int symbols_offsets[];
>> -#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
>> -#else
>> -extern const unsigned long symbols_addresses[];
>> -#define symbols_address(n) symbols_addresses[n]
>> -#endif
>> -extern const unsigned int symbols_num_syms;
>> -extern const u8 symbols_names[];
>> -
>> -extern const struct symbol_offset symbols_sorted_offsets[];
>> -
>> -extern const u8 symbols_token_table[];
>> -extern const u16 symbols_token_index[];
>> -
>> -extern const unsigned int symbols_markers[];
>> -
>> /* expand a compressed symbol data into the resulting uncompressed
>> string,
>> given the offset to where the symbol is in the compressed stream
>> */
>> static unsigned int symbols_expand_symbol(unsigned int off, char
>> *result)
>> --- a/xen/include/xen/symbols.h
>> +++ b/xen/include/xen/symbols.h
>> @@ -33,4 +33,22 @@ struct symbol_offset {
>> uint32_t stream; /* .. in the compressed stream.*/
>> uint32_t addr; /* .. and in the fixed size address array. */
>> };
>> +
>> +#ifdef SYMBOLS_ORIGIN
>> +extern const unsigned int symbols_offsets[];
>> +#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
>> +#else
>> +extern const unsigned long symbols_addresses[];
>> +#define symbols_address(n) symbols_addresses[n]
>> +#endif
>> +extern const unsigned int symbols_num_syms;
>> +extern const u8 symbols_names[];
>> +
>> +extern const struct symbol_offset symbols_sorted_offsets[];
>> +
>> +extern const u8 symbols_token_table[];
>> +extern const u16 symbols_token_index[];
>> +
>> +extern const unsigned int symbols_markers[];
>> +
>> #endif /*_XEN_SYMBOLS_H*/
>
> This change is even less clear to me: The producer is assembly code,
> and the consumer already had appropriate declarations. Why would we
> want to increase the scope of their visibility?
>
> Jan
The missing decls are about common/symbols-dummy.c. Xen can choose that
this file does
not need to conform (to this guideline or any guideline), in which case
this change can be dropped.
[1] https://lore.kernel.org/xen-devel/ZRqkbeVUZbjizjNv@MacBookPdeRoger/
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
On 16.10.2023 19:05, Nicola Vetrini wrote:
> On 16/10/2023 16:50, Jan Beulich wrote:
>> On 09.10.2023 08:54, Nicola Vetrini wrote:
>>> --- a/xen/arch/x86/include/asm/compat.h
>>> +++ b/xen/arch/x86/include/asm/compat.h
>>> @@ -13,6 +13,7 @@ typedef unsigned long full_ptr_t;
>>>
>>> struct domain;
>>> #ifdef CONFIG_PV32
>>> +extern unsigned long cr4_pv32_mask;
>>
>> Why is this needed? Didn't we say declarations aren't needed when the
>> only consumer is assembly code? (I also wonder how this header is any
>> more "appropriate" - see the changelog entry - than about any other
>> one.)
>>
>
> It was pointed out to me [1] that compat.h might be more appropriate
> than setup.h
> (probably because the asm code referencing it is under x86_64/compat).
Hmm. I agree setup.h isn't appropriate.
> Further, while it's true that this variable is used in asm, it's also
> used in x86/setup.c, hence
> the need for a declaration.
But that's the file where the variable is defined. IOW no risk of
definition and (non-existing) declaration going out of sync.
>>> --- a/xen/arch/x86/include/asm/setup.h
>>> +++ b/xen/arch/x86/include/asm/setup.h
>>> @@ -13,6 +13,7 @@ extern char __2M_rwdata_start[], __2M_rwdata_end[];
>>> extern unsigned long xenheap_initial_phys_start;
>>> extern uint64_t boot_tsc_stamp;
>>>
>>> +extern char cpu0_stack[STACK_SIZE];
>>
>> Same question here.
>>
>
> This one is a bit more nuanced (I wouldn't oppose deviating this), but
> there is indeed one use.
Still same here then.
>>> --- a/xen/common/symbols.c
>>> +++ b/xen/common/symbols.c
>>> @@ -21,23 +21,6 @@
>>> #include <xen/guest_access.h>
>>> #include <xen/errno.h>
>>>
>>> -#ifdef SYMBOLS_ORIGIN
>>> -extern const unsigned int symbols_offsets[];
>>> -#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
>>> -#else
>>> -extern const unsigned long symbols_addresses[];
>>> -#define symbols_address(n) symbols_addresses[n]
>>> -#endif
>>> -extern const unsigned int symbols_num_syms;
>>> -extern const u8 symbols_names[];
>>> -
>>> -extern const struct symbol_offset symbols_sorted_offsets[];
>>> -
>>> -extern const u8 symbols_token_table[];
>>> -extern const u16 symbols_token_index[];
>>> -
>>> -extern const unsigned int symbols_markers[];
>>> -
>>> /* expand a compressed symbol data into the resulting uncompressed
>>> string,
>>> given the offset to where the symbol is in the compressed stream
>>> */
>>> static unsigned int symbols_expand_symbol(unsigned int off, char
>>> *result)
>>> --- a/xen/include/xen/symbols.h
>>> +++ b/xen/include/xen/symbols.h
>>> @@ -33,4 +33,22 @@ struct symbol_offset {
>>> uint32_t stream; /* .. in the compressed stream.*/
>>> uint32_t addr; /* .. and in the fixed size address array. */
>>> };
>>> +
>>> +#ifdef SYMBOLS_ORIGIN
>>> +extern const unsigned int symbols_offsets[];
>>> +#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
>>> +#else
>>> +extern const unsigned long symbols_addresses[];
>>> +#define symbols_address(n) symbols_addresses[n]
>>> +#endif
>>> +extern const unsigned int symbols_num_syms;
>>> +extern const u8 symbols_names[];
>>> +
>>> +extern const struct symbol_offset symbols_sorted_offsets[];
>>> +
>>> +extern const u8 symbols_token_table[];
>>> +extern const u16 symbols_token_index[];
>>> +
>>> +extern const unsigned int symbols_markers[];
>>> +
>>> #endif /*_XEN_SYMBOLS_H*/
>>
>> This change is even less clear to me: The producer is assembly code,
>> and the consumer already had appropriate declarations. Why would we
>> want to increase the scope of their visibility?
>
> The missing decls are about common/symbols-dummy.c. Xen can choose that
> this file does
> not need to conform (to this guideline or any guideline), in which case
> this change can be dropped.
Since symbols-dummy.c isn't used in the final binary, I'd prefer that.
Otherwise imo a new private header used by just the two files would want
introducing, to keep exposure limited.
Jan
On 17/10/2023 08:46, Jan Beulich wrote:
> On 16.10.2023 19:05, Nicola Vetrini wrote:
>> On 16/10/2023 16:50, Jan Beulich wrote:
>>> On 09.10.2023 08:54, Nicola Vetrini wrote:
>>>> --- a/xen/arch/x86/include/asm/compat.h
>>>> +++ b/xen/arch/x86/include/asm/compat.h
>>>> @@ -13,6 +13,7 @@ typedef unsigned long full_ptr_t;
>>>>
>>>> struct domain;
>>>> #ifdef CONFIG_PV32
>>>> +extern unsigned long cr4_pv32_mask;
>>>
>>> Why is this needed? Didn't we say declarations aren't needed when the
>>> only consumer is assembly code? (I also wonder how this header is any
>>> more "appropriate" - see the changelog entry - than about any other
>>> one.)
>>>
>>
>> It was pointed out to me [1] that compat.h might be more appropriate
>> than setup.h
>> (probably because the asm code referencing it is under x86_64/compat).
>
> Hmm. I agree setup.h isn't appropriate.
>
>> Further, while it's true that this variable is used in asm, it's also
>> used in x86/setup.c, hence
>> the need for a declaration.
>
> But that's the file where the variable is defined. IOW no risk of
> definition and (non-existing) declaration going out of sync.
>
This is an aspect specific to this variable, that unfortunately the rule
does not
capture. I'll deviate this in the next version of this series.
>>>> --- a/xen/arch/x86/include/asm/setup.h
>>>> +++ b/xen/arch/x86/include/asm/setup.h
>>>> @@ -13,6 +13,7 @@ extern char __2M_rwdata_start[],
>>>> __2M_rwdata_end[];
>>>> extern unsigned long xenheap_initial_phys_start;
>>>> extern uint64_t boot_tsc_stamp;
>>>>
>>>> +extern char cpu0_stack[STACK_SIZE];
>>>
>>> Same question here.
>>>
>>
>> This one is a bit more nuanced (I wouldn't oppose deviating this), but
>> there is indeed one use.
>
> Still same here then.
>
Same as above; it can be argued that there's no risk of anything going
out of sync.
>>>> --- a/xen/common/symbols.c
>>>> +++ b/xen/common/symbols.c
>>>> @@ -21,23 +21,6 @@
>>>> #include <xen/guest_access.h>
>>>> #include <xen/errno.h>
>>>>
>>>> -#ifdef SYMBOLS_ORIGIN
>>>> -extern const unsigned int symbols_offsets[];
>>>> -#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
>>>> -#else
>>>> -extern const unsigned long symbols_addresses[];
>>>> -#define symbols_address(n) symbols_addresses[n]
>>>> -#endif
>>>> -extern const unsigned int symbols_num_syms;
>>>> -extern const u8 symbols_names[];
>>>> -
>>>> -extern const struct symbol_offset symbols_sorted_offsets[];
>>>> -
>>>> -extern const u8 symbols_token_table[];
>>>> -extern const u16 symbols_token_index[];
>>>> -
>>>> -extern const unsigned int symbols_markers[];
>>>> -
>>>> /* expand a compressed symbol data into the resulting uncompressed
>>>> string,
>>>> given the offset to where the symbol is in the compressed stream
>>>> */
>>>> static unsigned int symbols_expand_symbol(unsigned int off, char
>>>> *result)
>>>> --- a/xen/include/xen/symbols.h
>>>> +++ b/xen/include/xen/symbols.h
>>>> @@ -33,4 +33,22 @@ struct symbol_offset {
>>>> uint32_t stream; /* .. in the compressed stream.*/
>>>> uint32_t addr; /* .. and in the fixed size address array. */
>>>> };
>>>> +
>>>> +#ifdef SYMBOLS_ORIGIN
>>>> +extern const unsigned int symbols_offsets[];
>>>> +#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
>>>> +#else
>>>> +extern const unsigned long symbols_addresses[];
>>>> +#define symbols_address(n) symbols_addresses[n]
>>>> +#endif
>>>> +extern const unsigned int symbols_num_syms;
>>>> +extern const u8 symbols_names[];
>>>> +
>>>> +extern const struct symbol_offset symbols_sorted_offsets[];
>>>> +
>>>> +extern const u8 symbols_token_table[];
>>>> +extern const u16 symbols_token_index[];
>>>> +
>>>> +extern const unsigned int symbols_markers[];
>>>> +
>>>> #endif /*_XEN_SYMBOLS_H*/
>>>
>>> This change is even less clear to me: The producer is assembly code,
>>> and the consumer already had appropriate declarations. Why would we
>>> want to increase the scope of their visibility?
>>
>> The missing decls are about common/symbols-dummy.c. Xen can choose
>> that
>> this file does
>> not need to conform (to this guideline or any guideline), in which
>> case
>> this change can be dropped.
>
> Since symbols-dummy.c isn't used in the final binary, I'd prefer that.
> Otherwise imo a new private header used by just the two files would
> want
> introducing, to keep exposure limited.
>
> Jan
Ok
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
On Mon, 9 Oct 2023, Nicola Vetrini wrote: > Some variables with external linkage used in C code do not have > a visible declaration where they are defined. Providing such > declaration also resolves violations of MISRA C:2012 Rule 8.4. > > Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
© 2016 - 2026 Red Hat, Inc.