[clang] Diagnose problematic uses of constructor/destructor attribute (PR #67360)

Alexander Richardson via cfe-commits cfe-commits at lists.llvm.org
Wed Sep 27 07:59:33 PDT 2023


arichardson wrote:

> > With regard to arguments: I know that the [FreeBSD runtime linker](https://github.com/freebsd/freebsd-src/blob/d06328c37bbcf3d3d3c7601372d29237996a6f6a/libexec/rtld-elf/aarch64/rtld_machdep.h#L59) (and according to https://stackoverflow.com/a/46331112 also glibc) passes argc, argv, envv to the constructor functions, so maybe that specific signature should be permitted?
> 
> Thank you for pointing this out!
> 
> That is an undocumented behavior of the attribute that I think only happens to work if the stars line up correctly. As I understand things, glibc does this, but musl does not and it seems MSVC CRT does something entirely different as well. Because we don't know which CRT will be loaded at runtime, it seems pretty dangerous to allow that behavior. We could maybe presume glibc on ELF targets, but it seems like a lot of security risk to support an undocumented use case. Do you know if this is documented somewhere and I'm just not seeing it? Any ideas on how we can add safety rails instead of allowing the signature and hoping for the best?

I did not realize musl doesn't pass arguments - in that case the only safe option is to reject arguments.

Hopefully the number of constructors that expect getting arguments is extremely rare. But I do worry that there is code out there that assumes glibc behaviour, so it seems to me that err_ctor_dtor_attr_on_non_void_func needs to be a warning-as-error that can be downgraded? 

https://github.com/llvm/llvm-project/pull/67360


More information about the cfe-commits mailing list