| Message ID | c4b7f6ce-baa9-4b55-bdea-a67ff7d5daa1@suse.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | symbols: assorted adjustments | expand |
On 13/03/2025 1:53 pm, Jan Beulich wrote: > Parameter and return types of symbols_expand_symbol() make clear that > xensyms_read()'s next_offset doesn't need to be 64-bit. > > xensyms_read()'s first parameter type makes clear that the function's > next_symbols doesn't need to be 64-bit. > > symbols_num_syms'es type makes clear that iteration locals in > symbols_lookup() don't need to be unsigned long (i.e. 64-bit on 64-bit > architectures). > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- a/xen/common/symbols.c +++ b/xen/common/symbols.c @@ -108,7 +108,7 @@ const char *symbols_lookup(unsigned long unsigned long *offset, char *namebuf) { - unsigned long i, low, high, mid; + unsigned int i, low, high, mid; unsigned long symbol_end = 0; const struct virtual_region *region; @@ -179,7 +179,7 @@ int xensyms_read(uint32_t *symnum, char * from previous read. This can help us avoid the extra call to * get_symbol_offset(). */ - static uint64_t next_symbol, next_offset; + static unsigned int next_symbol, next_offset; static DEFINE_SPINLOCK(symbols_mutex); if ( *symnum > symbols_num_syms )
Parameter and return types of symbols_expand_symbol() make clear that xensyms_read()'s next_offset doesn't need to be 64-bit. xensyms_read()'s first parameter type makes clear that the function's next_symbols doesn't need to be 64-bit. symbols_num_syms'es type makes clear that iteration locals in symbols_lookup() don't need to be unsigned long (i.e. 64-bit on 64-bit architectures). Signed-off-by: Jan Beulich <jbeulich@suse.com>