On Tue, Feb 06, 2024 at 01:50:14PM +0100, Jakub Jelinek wrote:
> On Tue, Feb 06, 2024 at 12:38:31PM +0000, Richard W.M. Jones wrote:
> > Not sure if it helps but it seems these source files implement the
> > plugin:
> > 
> > https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/afl-gcc-cmplog-pass.so.cc
> > https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/afl-gcc-cmptrs-pass.so.cc
> > https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/afl-gcc-pass.so.cc
> > 
> > and this header:
> > 
> > https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/afl-gcc-common.h
> > 
> > At a glance it seems like it uses a lot of APIs ...
> 
> >From quick skimming, I've only noticed
>     set_decl_tls_model(
>         decl, (flag_pic ? TLS_MODEL_INITIAL_EXEC : TLS_MODEL_LOCAL_EXEC));
> where flag_pic can change any time some option is added or removed from
> *.opt files.
> But, it doesn't seem correct either, I think it should use
>     set_decl_tls_model(decl, decl_default_tls_model(decl));
> instead.  Or call decl_default_tls_model(decl) and adjust the result
> depending on what it will return.

BTW, if flag_pic ? TLS_MODEL_INITIAL_EXEC : TLS_MODEL_LOCAL_EXEC is
really what the plugins wants (e.g. that the TLS variable will be
defined in the same executable or same shared library and for shared
library doesn't mind making it non-dlopenable if other libraries deplete
the static TLS size), one hack might be to use e.g.
default_reloc_rw_mask () ? TLS_MODEL_INITIAL_EXEC : TLS_MODEL_LOCAL_EXEC
where default_reloc_rw_mask () is defined as return flag_pic ? 3 : 0;
for almost 17 years already, so could be a quick hack around trying to
remap flag_pic.

I'd really like to avoid exact gcc NVR dependency, at least if any gcc
updates would be refused because of that until somebody rebuilds the plugin
as well.  That was a reason why annobin has been changed to do the option
remapping...

        Jakub
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to