libsanitizer: Hwasan reporting check for dladdr failing

[Matthew Malcomson]

On 24/11/2020 15:53, Kyrylo Tkachov wrote:
> Hi Matthew,
> 
>> -----Original Message-----
>> From: Gcc-patches <gcc-patches-bounces@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.Sandiford@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.

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);
>