On Fri, 2023-08-04 at 11:02 -0400, Eric Feng wrote:
> Hi Dave,
>
> Tests related to our plugin which depend on Python-specific
> definitions have been run by including /* { dg-options "-fanalyzer
> -I/usr/include/python3.9" } */. This is undoubtedly not ideal; is it
> best to approach this problem by adapting a subset of relevant
> definitions like in gil.h?
That might be acceptable in the very short-term, but to create a plugin
that's useful to end-user (authors of CPython extension modules) we
want to be testing against real Python headers.
As I understand it, https://peps.python.org/pep-0394/ allows for
distributors of Python to symlink "python3-config" in the PATH to a
python3.X-config script (for some X).
So on such systems running:
python3-config --includes
should emit the correct -I option. On my box it emits:
-I/usr/include/python3.8 -I/usr/include/python3.8
It's more complicated, but I believe:
python3-config --cflags
should emit the build flags that C/C++ extensions ought to use when
building. On my box this emits:
-I/usr/include/python3.8 -I/usr/include/python3.8 -Wno-unused-result -
Wsign-compare -O2 -g -pipe -Wall -Werror=format-security -Wp,-
D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-
protector-strong -grecord-gcc-switches -m64 -mtune=generic -
fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -
D_GNU_SOURCE -fPIC -fwrapv -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -
O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-
D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-
gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables -
fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv
and it's likely going to vary from distribution to distribution. Some
of those options *are* going to affect the gimple that -fanalyzer
"sees".
Does your installation of Python have such a script?
So in the short term you could hack in a minimal subset of the
decls/defns from Python.h, but I'd prefer it if target-supports.exp
gained a DejaGnu directive that invokes python3-config, captures the
result (or fails with UNSUPPORTED for systems without python3
development headers), and then adds the result to the build flags of
the file being tested. The .exp files are implemented in Tcl, alas;
let me know if you want help with that.
Dave
>
> Best,
> Eric
>
> On Tue, Aug 1, 2023 at 1:06 PM David Malcolm <dmalc...@redhat.com>
> wrote:
> >
> > On Tue, 2023-08-01 at 09:57 -0400, Eric Feng wrote:
> > > >
> > > > My guess is that you were trying to do it from the
> > > > PLUGIN_ANALYZER_INIT
> > > > hook rather than from the plugin_init function, but it's hard
> > > > to be
> > > > sure without seeing the code.
> > > >
> > >
> > > Thanks Dave, you are entirely right — I made the mistake of
> > > trying to
> > > do it from PLUGIN_ANALYZER_INIT hook and not from the plugin_init
> > > function. After following your suggestion, the callbacks are
> > > getting
> > > registered as expected.
> >
> > Ah, good.
> >
> > > I submitted a patch to review for this feature
> > > on gcc-patches; please let me know if it looks OK.
> >
> > Thanks Eric; I've posted a reply to your email there, so let's
> > discuss
> > the details there.
> >
> > Dave
> >
>
