On Sat, Jul 18, 2020 at 11:40 AM Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
>
> When checking a series of files, if some warnings or errors
> are issued but only coming from some includes, it's not possible
> to identify which source file is responsible since its filename
> is not displayed.
>
> So, if the first warning is from a file other than the source
> file, display first a note coming from the source file itself.
This really isn't enough when the include chain is deeper and more complex.
How about something a bit more complex? This is only lightly tested,
but I don't have time for anything more right now..
It results in things like
kernel/exit.c: note: in included file (through
include/linux/sched/signal.h, include/linux/rcuwait.h,
include/linux/percpu-rwsem.h, include/linux/fs.h,
include/linux/huge_mm.h, include/linux/mm.h):
./include/linux/sched/task.h:115:34: warning: context imbalance in
'wait_task_zombie' - unexpected unlock
./include/linux/sched/task.h:115:34: warning: context imbalance in
'wait_task_stopped' - unexpected unlock
./include/linux/sched/task.h:115:34: warning: context imbalance in
'wait_task_continued' - unexpected unlock
to give an example of a warning happening in a header file that got
included through a deeper chain.
That stream chaining information might perhaps be useful for other cases too?
Would it be better to save the whole 'pos' for the chain, so that
you'd get line numbers etc for the chain? Probably. As mentioned, this
is a quick "how about something like this".
If you extend it and do more testing, you can have my sign-off, or
just take ownership of the patch entirely with my ack..
Now off for more kernel stuff after a quick sparse excursion...
Linus
Attachment:
patch
Description: Binary data
