[PATCH] ld/PDB: use correct hashing algorithm in add_globals_ref

Jan Beulich jbeulich@suse.com
Tue Jul 16 06:35:30 GMT 2024


On 16.07.2024 01:36, Mark Harmstone wrote:
> On 15/07/2024 07:26, Jan Beulich wrote:
>> On 13.07.2024 16:53, Mark Harmstone wrote:
>>> add_globals_ref was hashing using CRC32 rather than the hashing
>>> algorithm used for symbols, which meant that windbg was unable to put
>>> breakpoints against unmangled names.
>>
>> For those of us not that familiar with PDBs, would you please provide a
>> reference to where it is said what's right here?
> 
> This isn't documented - it appears to be part of the microsoft-pdb repo
> that they declined to publish (hence why I got it wrong initially).
> 
> The linker generates S_PUB32 symbols which use the mangled names, and
> the compiler generates S_[GL]PROC32 symbols which use the unmangled
> names. Windbg can parse both when setting breakpoints.
> It was only when adding CodeView support to GCC that this mistake
> became obvious.

Hmm, makes it hard to approve such a patch then. But yeah, what do we do
in such a situation, so: Okay.

>>> \ No newline at end of file
>>
>> While you're touching this file, can you please also take care of this
>> lack of a newline?
> 
> This is intentional, the tests break if a newline is added.

Well, no, something _is_ wrong then. There better wouldn't be any such
files. Assuming that even adding #pass would still result in such breakage
(all of this testing being open-coded makes me infer that constructs like
#pass can't be used here at all), I'm inclined to assume objdump is
producing bogus output then. Or the output is wrongly stripped of the
trailing newline when processed by the testing machinery. A simple test of
"objdump -s --target=binary" suggests the latter, albeit the
"set exp [file_contents ...]" looks innocent enough.

Jan


More information about the Binutils mailing list