[lld] r232251 - [ELF] Fix DenseMapInfo for StringRef

[Shankar Easwaran]

On 3/14/2015 1:52 PM, David Blaikie wrote:
> On Fri, Mar 13, 2015 at 10:26 PM, Shankar Easwaran <shankare at codeaurora.org>
> wrote:
>
>> Author: shankare
>> Date: Sat Mar 14 00:26:55 2015
>> New Revision: 232251
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=232251&view=rev
>> Log:
>> [ELF] Fix DenseMapInfo for StringRef
>>
>> Modified:
>>      lld/trunk/lib/ReaderWriter/ELF/SectionChunks.h
>>
>> Modified: lld/trunk/lib/ReaderWriter/ELF/SectionChunks.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/lld/trunk/lib/ReaderWriter/ELF/SectionChunks.h?rev=232251&r1=232250&r2=232251&view=diff
>>
>> ==============================================================================
>> --- lld/trunk/lib/ReaderWriter/ELF/SectionChunks.h (original)
>> +++ lld/trunk/lib/ReaderWriter/ELF/SectionChunks.h Sat Mar 14 00:26:55 2015
>> @@ -574,7 +574,7 @@ private:
>>
>>     struct StringRefMappingInfo {
>>       static StringRef getEmptyKey() { return StringRef(); }
>> -    static StringRef getTombstoneKey() { return StringRef(" ", 0); }
>> +    static StringRef getTombstoneKey() { return StringRef(" ", 1); }
>>
> These look really questionable/problematic - they're totally valid
> StringRef values  - I imagine maybe using the max value for a pointer (or
> for the length, or both) might be more suitable, but I haven't looked at a
> variety of DenseMap tombstones, etc, to see what's common.
In the context of when strings are being added to the StringTable(where 
the StringRefMappingInfo is used), the empty tombstone key is not valid.

>
>
>>       static unsigned getHashValue(StringRef const val) {
>>         return llvm::HashString(val);
>>       }
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation