bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded

[Daniel Colascione]

>> From: Pip Cet <pipcet@gmail.com>
>> Date: Mon, 6 Jan 2020 15:51:57 +0000
>> Cc: NiwTinray <niwtrx@icloud.com>, Daniel Colascione
>> <dancol@dancol.org>, 38912@debbugs.gnu.org
>>
>> >   #2  0x01326817 in check_hash_table_rehash
>> (table_orig=XIL(0xa000000006288090))
>> >       at pdumper.c:2684
>>
>> Can you confirm table_orig is cl--generic-dispatchers?
>
> I don't think I know how.  Hash tables don't seem to have names stored
> in them, do they?  (If they did, I'd expect xhashtable to print that
> name.)
>
>> Again, I doubt this is related to the original bug. That `equal'
>> behaves weirdly like this is a problem I've mentioned before (when
>> (equal a b) signals but (equal b a) succeeds), but the consensus then
>> was not to change it, so it's possible this is only the rehashing
>> check needing to be more careful.

This consensus is wrong. We need to make equality imply sxhash equality or
very odd things (like this) will happen. C++ and Java both require this
relationship between hash code equality and object equality, and we should
too. Can we just fix the bytecode sxhash bug?