On Tue, 2022-06-21 at 18:50 +0000, Joseph Myers wrote:
> On Tue, 21 Jun 2022, David Malcolm via Gcc wrote:
>
> > So ultimately that's something we want to fix, though exactly how,
> > I'm
> > not quite sure; we presumably want to look up the target's
> > definitions
> > of those macros - but I don't think the analyzer has access to the
> > cpp_reader instance from the frontend.
>
> Normally that would use a target hook to specify the values of those
> macros. The default would be the traditional Unix values of 0, 1, 2
> for
> O_RDONLY, O_WRONLY, O_RDWR, while Hurd would need its own definition of
> the hook to use values 1, 2, 3 (I don't know if there are any non-Hurd
> systems not using the traditional values).
I found that it's at least theoretically possible to access the
preprocessor from within the analyzer; e.g. given:
#define O_RDONLY 42
and then breaking in the debugger in ana::run_checkers:
(gdb) p cpp_lookup (parse_in, (unsigned char *)"O_RDONLY",
(size_t)strlen ("O_RDONLY"))
$1 = (cpp_hashnode *) 0x7fffea794248
(gdb) p *$1
$2 = {ident = {str = 0x7fffea7877d0 "O_RDONLY", len = 8, hash_value =
3761648590}, is_directive = 0, directive_index = 0, rid_code = 0, flags
= 0, type = NT_USER_MACRO, deferred = 0, value = {answers =
0x7fffea7a5480, macro = 0x7fffea7a5480, builtin = 3933885568, arg_index
= 21632}}
(gdb) p $1->value.macro.exp.tokens.type
$6 = CPP_NUMBER
(gdb) p $1->value.macro.exp.tokens.val.str
$7 = {len = 2, text = 0x3ec182b "42"}
so given the C/C++ FEs it might be possible for the analyzer to try to
lookup the value of O_RDONLY.
But I'm wary of this; e.g. the LTO case, and for non-trivial macro
definitions.
Joseph: is the target hook the way to go with this? Would it look
something like:
DEFHOOK (fd_access_mode, "FIXME", int (int))
taking the build configuration's O_ access mode, and returning the
target configurations's access mode (so e.g fd_access_mode (O_RDONLY)
would return the target's int) ?
Thanks
Dave
