On Mon, Nov 21, 2016 at 11:50 AM, Jakub Jelinek <ja...@redhat.com> wrote: > On Mon, Nov 21, 2016 at 11:43:56AM +0000, Yuri Gribov wrote: >> > This is just weird. DECL_NAME in theory could be NULL, or can be a symbol >> > much longer than 100 bytes, at which point you have strlen (tmp_name) == 99 >> > and ASM_GENERATE_INTERNAL_LABEL will just misbehave. >> > I fail to see why you need tmp_name at all, I'd go just with >> > char sym_name[40]; >> > ASM_GENERATE_INTERNAL_LABEL (sym_name, "LASANODR", ++lasan_odr_ind_cnt); >> > or so. >> >> Given that feature is quite new and hasn't been tested too much (it's >> off by default in Clang), having a descriptive name may aid with >> debugging bug reports. > > What would those symbols help with in debugging bug reports? > You need to have a source reproducer anyway, then anybody can try it > himself.
Well, in case of some weird symbol error at startup we can at least understand which library/symbol to blame. > Even from just pure *.s file, you can look up where the > .LASANODR1234 is used and from there find the corresponding symbol. > Plus, as I said, with 95 chars or longer symbols (approx.) you get a buffer > overflow. We don't use descriptive symbols in other internal asan, dwarf2 > etc. labels. Note that indicators need to have default visibility so simple scheme like this will cause runtime collisions. -Iurii
