https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112562
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > find -type f | xargs grep %function > ./interception/interception.h: ".type " > SANITIZER_STRINGIFY(TRAMPOLINE(func)) ", %function\n" \ > ./builtins/assembly.h:#define SYMBOL_IS_FUNC(name) .type name,%function > ./sanitizer_common/sanitizer_asm.h:# define ASM_TYPE_FUNCTION(symbol) .type > symbol, %function > ./hwasan/hwasan_tag_mismatch_aarch64.S:.type __hwasan_tag_mismatch, %function > ./hwasan/hwasan_tag_mismatch_aarch64.S:.type __hwasan_tag_mismatch_v2, > %function I think we can ignore all of builtins/assembly.h and hwasan: neither is supported on Solaris/x86 or sparc. > I'm open to a local patch. > Shall we use @ except on aarch64/arm (sparc-svr4 not being supported in > libsanitizer I think), something else? I guess that's the easiest way out: we'd probably have to duplicate the condition in interception/interception.h and sanitizer_common/sanitizer_asm.h, unless we can find a way to share the @function/%function definition between both. gcc/config/sparc/svr4.h is used by sparc-linux, which is supported by libsanitizer (both upstream and gcc). > Though, builtins/assembly.h already has SYMBOL_IS_FUNC macro which ought to > DTRT, except that it is for *.S files and not for inline asm where things > should be stringified. It's only included in sanitizer_common/sanitizer_common_interceptors_vfork_aarch64.inc.S and several hwasan files, so I guess it can stay as is.
