> -----Original Message----- > From: Matthew Malcomson <matthew.malcom...@arm.com> > Sent: 24 November 2020 16:20 > To: Kyrylo Tkachov <kyrylo.tkac...@arm.com> > Cc: Richard Sandiford <richard.sandif...@arm.com>; gcc- > patc...@gcc.gnu.org > Subject: Re: libsanitizer: Hwasan reporting check for dladdr failing > > On 24/11/2020 15:53, Kyrylo Tkachov wrote: > > Hi Matthew, > > > >> -----Original Message----- > >> From: Gcc-patches <gcc-patches-boun...@gcc.gnu.org> On Behalf Of > >> Matthew Malcomson via Gcc-patches > >> Sent: 24 November 2020 15:47 > >> To: gcc-patches@gcc.gnu.org > >> Cc: Richard Sandiford <richard.sandif...@arm.com> > >> Subject: libsanitizer: Hwasan reporting check for dladdr failing > >> > >> Hello there, > >> > >> This is the compiler-rt patch I'd like to cherry-pick so that the hwasan > >> tests > >> pass. > >> > >> It is in LLVM as commit 83ac18205ec69a00ac2be3b603bc3a61293fbe89. > >> > >> Ok for trunk? > >> > >> Also is the libhwasan library merge from the below email OK for trunk? > >> https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558999.html > >> (Note I would also add a line to README.gcc mentioning compiler- > >> rt/lib/hwasan > >> on top of the changes in that patch). > >> > >> I would guess so, but wasn't certain the OK had ever been said anywhere. > > > > I believe merges from an upstream are generally considered pre-approved. > In any case, I see that merge committed as > 98f792ff538109c71d85ab2a61461cd090f3b9f3 > > > > Thanks, > > Kyrill > > Thanks Kyrill, > > For the record, 98f792ff538109c71d85ab2a61461cd090f3b9f3 is the merge > without libhwasan part, while I was asking about the libhwasan part. > > However, given the standard pre-approved merge from upstream status I > guess it doesn't matter -- and that's good to know for the future too.
Ah, I suppose in the sanitiser case as there are local modifications maybe it's not a straightforward pre-approval, so don't take my word on it 😉 Martin will probably know the rules here. Thanks, Kyrill > > Thanks! > Matthew > > > > >> > >> Regards, > >> Matthew > >> > >> ------------------------- > >> > >> > >> In `GetGlobalSizeFromDescriptor` we use `dladdr` to get info on the the > >> current address. `dladdr` returns 0 if it failed. > >> During testing on Linux this returned 0 to indicate failure, and > >> populated the `info` structure with a NULL pointer which was > >> dereferenced later. > >> > >> This patch checks for `dladdr` returning 0, and in that case returns 0 > >> from `GetGlobalSizeFromDescriptor` to indicate failure of identifying > >> the address. > >> > >> This occurs when `GetModuleNameAndOffsetForPC` succeeds for some > >> address > >> not in a dynamically loaded library. One example is when the found > >> "module" is '[stack]' having come from parsing /proc/self/maps. > >> > >> Cherry-pick from 83ac18205ec69a00ac2be3b603bc3a61293fbe89. > >> > >> Differential Revision: https://reviews.llvm.org/D91344 > >> > >> > >> ############### Attachment also inlined for ease of reply > >> ############### > >> > >> > >> diff --git a/libsanitizer/hwasan/hwasan_report.cpp > >> b/libsanitizer/hwasan/hwasan_report.cpp > >> index > >> > 0be7deeaee1a0bd523d9e0fe1dc3b1311b3920e2..894a149775f291bae9cad8 > >> 33b1ac54914212f405 100644 > >> --- a/libsanitizer/hwasan/hwasan_report.cpp > >> +++ b/libsanitizer/hwasan/hwasan_report.cpp > >> @@ -254,7 +254,8 @@ static bool TagsEqual(tag_t tag, tag_t *tag_ptr) { > >> static uptr GetGlobalSizeFromDescriptor(uptr ptr) { > >> // Find the ELF object that this global resides in. > >> Dl_info info; > >> - dladdr(reinterpret_cast<void *>(ptr), &info); > >> + if (dladdr(reinterpret_cast<void *>(ptr), &info) == 0) > >> + return 0; > >> auto *ehdr = reinterpret_cast<const ElfW(Ehdr) *>(info.dli_fbase); > >> auto *phdr_begin = reinterpret_cast<const ElfW(Phdr) *>( > >> reinterpret_cast<const u8 *>(ehdr) + ehdr->e_phoff); > >
