[Bug analyzer/109266] Wanalyzer-null-dereference does not warn when struct is at null

["jg at jguk dot org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266

--- Comment #5 from Jonny Grant <jg at jguk dot org> ---
(In reply to David Malcolm from comment #3)
> (In reply to Jonny Grant from comment #2)
> > Thank you for your reply David. Your analyzer is very good already.
> > 
> > I played around a bit, a base of nullptr doesn't give a warning. But
> > changing to 0x10 does give array-bounds warning.
> > cc1plus: note: source object is likely at address zero
> > <source>:13:13: warning: array subscript 0 is outside array bounds of 'a_t
> > [0]' [-Warray-bounds=]
> > 
> > https://godbolt.org/z/PhhT48xxP
> 
> FWIW, note that [-Warray-bounds=] is separate from -fanalyzer.
> 
> > 
> > Found Andrew Pinski comment says 4096 is not accessible:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106699#c1
> 
> Aha - thanks for the link!  I think that's the thing that I was
> half-remembering (well, its dup, PR 99578), and that it was, in fact, in GCC.
> 
> Looks like I should extend -Wanalyzer-null-dereference to warn about
> accesses to constant addresses, but have it respect --param=min-pagesize=
> (see r11-9731-g91f7d7e1bb6827bf8e0b7ba7eb949953a5b1bd18).  This would have
> to wait for GCC 14 at this point in the release cycle.
> 
> > 
> > I wondered if you know how to turn on that "cc1plus: note: source object is
> > likely at address zero? It seems different from normal warnings.
> 
> Grepping the sources shows it's from gcc/pointer-query.cc:
> access_ref::inform_access; I think it's one of the middle-end warnings that
> triggers that, but I'm not sure exactly which (the analyzer doesn't use that
> at the moment).

Many thanks for your investigation and reply.


> > It would be fantastic if there was a way for me to specify on the gcc
> > command line an address range I didn't want read and/or writable. That would
> > be great to get build warnings from those addresses if the compiler could
> > see them being accessed.
> 
> Is this always for stuff near the 0 address, or are there other use cases? 
> (embedded?)  Are you able to post an example here of what the input might
> look like?

For me, I was mainly thinking issues due to reading near the 0x0 address (which
is valid containing some stuff like the interrupt vector of function pointers
etc). The best example would be the struct at NULL I put on godbolt.

However, it is true that reading from other addresses that aren't HW mapped IO,
RAM or Flash etc would also lead to faults, so if there was a way to specify
the valid address ranges that would be great. I recall another compiler I used
did let me specify valid ranges.

Jonathan Wakely mentioned  __attribute__((access(read_only, 1)));  elsewhere it
could imply the pointer was non-null (I couldn't get any build warnings through
use of that attribute though in GCC 12). I don't know if the Analyzer could use
that attribute too.


> > 
> > At the moment, I always need to use the JTAG debugger to set some hw
> > breakpoints on read from various addresses to catch those accesses (as they
> > are mapped to the interrupt vector from 0x0). On Windows I've had various
> > crashes where the access was address 0x10 so felt like that was probably a
> > struct offset too
> > 
> > I don't know very much about gcc internals. I did wonder if the analyzer can
> > see the base address of the struct being passed as 0x0 in the RTL file?
> > I tried -fdump-rtl-all but couldn't see the 0x0 address, or when I changed
> > to 0x10 either
> 
> The analyzer works on the gimple-ssa representation, which is before it
> become RTL.  If you want to see the gory details, have a look in:
>   https://gcc.gnu.org/onlinedocs/gccint/Analyzer-Internals.html
> in the gcc internal docs, and:
>   https://gcc-newbies-guide.readthedocs.io/en/latest/inside-cc1.html
> in the guide for new gcc contributors I wrote.

Thank thanks for the links.

I modified the above example to have a base of 0x100 and noticed it in the SSA
file

MEM[(struct a_t *)256B].c[0] = 98;

In the resulting ASM output, it was 8 bytes offset from the base. 0x108

Would be great if Analyzer could report on these in a future release.