On Wed, Feb 19, 2020 at 10:16 AM Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > On Wed, Feb 19, 2020 at 09:44:31AM -0800, Nick Desaulniers wrote: > > Hey Nathan, > > Thanks for the series; enabling the warning will help us find more > > bugs. Revisiting what the warning is about, I checked on this > > "referring to symbols defined in linker scripts from C" pattern. This > > document [0] (by no means definitive, but I think it has a good idea) > > says: > > > > Linker symbols that represent a data address: In C code, declare the > > variable as an extern variable. Then, refer to the value of the linker > > symbol using the & operator. Because the variable is at a valid data > > address, we know that a data pointer can represent the value. > > Linker symbols for an arbitrary address: In C code, declare this as an > > extern symbol. The type does not matter. If you are using GCC > > extensions, declare it as "extern void". > > > > Indeed, it seems that Clang is happier with that pattern: > > https://godbolt.org/z/sW3t5W > > > > Looking at __stop___trace_bprintk_fmt in particular: > > > > kernel/trace/trace.h > > 1923:extern const char *__stop___trace_bprintk_fmt[]; > > Godbolt says clang is happy if it is written as: > > if (&__stop___trace_bprintk_fmt[0] != &__start___trace_bprintk_fmt[0]) > > Which is probably the best compromise. The type here is const char > *[], so it would be a shame to see it go. If the "address" is never dereferenced, but only used for arithmetic (in a way that the the pointed to type is irrelevant), does the pointed to type matter? I don't feel strongly either way, but we seem to have found two additional possible solutions for these warnings, which is my ultimate goal. Nathan, hopefully those are some ideas you can work with to address the additional cases throughout the kernel? -- Thanks, ~Nick Desaulniers
