[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v5 1/4] xen: introduce CONFIG_GENERIC_BUG_FRAME
On Tue, 2023-03-07 at 14:16 +0100, Jan Beulich wrote: > On 07.03.2023 14:13, Oleksii wrote: > > > > > > > + > > > > > > > +#define BUG_FRAME(type, line, ptr, second_frame, msg) do > > > > > > > { \ > > > > > > > + BUILD_BUG_ON((line) >> (BUG_LINE_LO_WIDTH + > > > > > > > BUG_LINE_HI_WIDTH)); \ > > > > > > > + BUILD_BUG_ON((type) >= > > > > > > > BUGFRAME_NR); \ > > > > > > > + asm volatile ( > > > > > > > _ASM_BUGFRAME_TEXT(second_frame) > > > > > > > \ > > > > > > > + :: _ASM_BUGFRAME_INFO(type, line, > > > > > > > ptr, > > > > > > > msg) > > > > > > > ); \ > > > > > > > +} while (0) > > > > > > > > > > Isn't this tied to BUG_FRAME_STRUCT being defined (or not)? > > > > > At > > > > > least > > > > > the 1st BUILD_BUG_ON() looks problematic if an arch wasn't to > > > > > use > > > > > the generic struct: With how you have things right now > > > > > BUG_LINE_{LO,HI}_WIDTH may not be defined, and the check > > > > > would > > > > > also > > > > > be at risk of causing false positives. Perhaps it's > > > > > appropriate > > > > > to > > > > > have a separate #ifdef (incl the distinct identifier used), > > > > > but > > > > > that > > > > > first BUILD_BUG_ON() needs abstracting out. > > > Missed that. Thanks. > > > I'll introduce that a separate #ifdef before BUG_FRAME: > > > > > > #ifndef BUILD_BUG_ON_LINE_WIDTH > > > #define BUILD_BUG_ON_LINE_WIDTH \ > > > BUILD_BUG_ON((line) >> (BUG_LINE_LO_WIDTH + > > > BUG_LINE_HI_WIDTH)) > > > #endif > > I think even better will be to do in the following way: > > > > #ifndef LINE_WIDTH > > #define LINE_WIDTH (BUG_LINE_LO_WIDTH + BUG_LINE_HI_WIDTH) > > #endif > > > > #define BUG_FRAME(type, line, ptr, second_frame, msg) do > > { > > \ > > BUILD_BUG_ON((line) >> > > LINE_WIDTH); > > \ > > BUILD_BUG_ON((type) >= > > BUGFRAME_NR); > > \ > > asm volatile ( > > _ASM_BUGFRAME_TEXT(second_frame) > > \ > > :: _ASM_BUGFRAME_INFO(type, line, ptr, msg) > > ); > > \ > > } while (false) > > Not sure - that'll still require arches to define LINE_WIDTH. What > if they store the line number in a 32-bit field? Then defining > LINE_WIDTH to 32 would yield undefined behavior here. > It might be an issue. Than it will be better to have function-like macros mentioned in previous e-mail. Thanks ~ Oleksii
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |