[Bug analyzer/109266] Wanalyzer-null-dereference does not warn when struct is at null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266 --- Comment #5 from Jonny Grant --- (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 > > :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.
[Bug analyzer/109266] Wanalyzer-null-dereference does not warn when struct is at null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266 --- Comment #4 from David Malcolm --- (In reply to David Malcolm from comment #3) > (In reply to Jonny Grant from comment #2) [...] > > > > 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). Grepping for calls to "inform_access" shows that it can come from: -Warray_bounds= -Wstringop_overflow= -Wstringop_overread
[Bug analyzer/109266] Wanalyzer-null-dereference does not warn when struct is at null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266 --- Comment #3 from David Malcolm --- (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 > :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). > 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? > > 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.
[Bug analyzer/109266] Wanalyzer-null-dereference does not warn when struct is at null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266 --- Comment #2 from Jonny Grant --- 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 :13:13: warning: array subscript 0 is outside array bounds of 'a_t [0]' [-Warray-bounds=] https://godbolt.org/z/PhhT48xxP Found Andrew Pinski comment says 4096 is not accessible: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106699#c1 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. 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. 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
[Bug analyzer/109266] Wanalyzer-null-dereference does not warn when struct is at null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266 --- Comment #1 from David Malcolm --- Thanks for filing this bug. We probably want to allow accesses to hard-coded addresses, for the case of embedded development, so we presumably need some way to distinguish between accesses of: ((struct foo *)NULL->field) due to buggy code versus poking specific memory locations. One approach to this might be for the analyzer to complain if it sees a memory access to a "low enough" address: rather than merely complaining about accesses to memory location 0, to have some kind of configurable threshold of pointer values below which to complain, e.g. "complain about accesses to locations 0 through 4095". I dimly recall something similar to this inside the Linux kernel at run time - what memory accesses close to NULL should trigger a crash - but I can't find a reference right now.
