[PATCH v3] bfd: fill in PE load config directory entry.

[Jan Beulich]

On 20.03.2025 19:22, Jeremy Drake wrote:
> On Thu, 20 Mar 2025, Jan Beulich wrote:
>> On 13.03.2025 18:14, Jeremy Drake wrote:
>>> @@ -4573,6 +4575,48 @@ _bfd_XXi_final_link_postscript (bfd * abfd, struct coff_final_link_info *pfinfo)
>>>  #endif
>>>      }
>>>
>>> +  h1 = coff_link_hash_lookup (coff_hash_table (info),
>>> +			      (bfd_get_symbol_leading_char (abfd) != 0
>>> +			       ? "__load_config_used" : "_load_config_used"),
>>
>> Still assuming bfd_get_symbol_leading_char() can only ever return nil or '_'?
> 
> Yes:
>> Nevertheless, because of the pre-existing similar code, I'm not going to
>> insist that this be corrected right here.

Oh, right, I said that earlier on. A remark towards the limitation in the
commit message would maybe help.

>> I wonder if we can indeed blindly use that value, with no sanity checking
>> whatsoever.
>>
>> Furthermore, having checked two random executables each from two random VC
>> installations, I find that the size in the data directory and the value at
>> the start of the referenced RVA aren't the same: In all four cases the data
>> directory says 0x40 while the 32-bit item at the indicated RVA is 0x48.
> 
> That's odd.  This matches what LLD does (though they do indeed do some
> sanity checking):
> https://github.com/llvm/llvm-project/blob/49f06075a6d298bd13564c9bffcf51281bed4962/lld/COFF/SymbolTable.cpp#L576

As one more data point, a quote from MS doc: "For Windows XP, the size must
be specified as 64 for x86 images." It looks odd to me though that the exact
same size is stated for both the 32- and 64-bit struct.

Since hopefully hardly anyone still cares about XP, doing what you do (and
what llvm does) is likely fine, but imo wants to come with a code comment
then.

Jan