================
@@ -1036,12 +1036,18 @@ void ObjectFilePECOFF::CreateSections(SectionList
&unified_section_list) {
m_sections_up->AddSection(header_sp);
unified_section_list.AddSection(header_sp);
+ std::vector<llvm::StringRef> truncated_dwarf_sections;
const uint32_t nsects = m_sect_headers.size();
for (uint32_t idx = 0; idx < nsects; ++idx) {
llvm::StringRef sect_name = GetSectionName(m_sect_headers[idx]);
ConstString const_sect_name(sect_name);
SectionType section_type = GetSectionType(sect_name,
m_sect_headers[idx]);
+ // Detect unknown sections matching ^\.debug_[a-z]$
+ if (section_type == eSectionTypeOther && sect_name.size() == 8 &&
----------------
Nerixyz wrote:
> Besides the point of this PR, but is there any information about whether
> link.exe does this too, or if it's just an escape route for third parties?
It is officially documented in the [name
field](https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#section-table-section-headers)
of the COFF header.
I don't know when/if link.exe will ever generate this indirect section name (I
think it will always emit executable images).
So it's non-standard (lld-link also warns: `section name .debug_abbrev is
longer than 8 characters and will use a non-standard string table` - MinGW's
`ld` does this without any warning), but supported by most tools - even
Microsoft's dumpbin will happily output the long section names.
https://github.com/llvm/llvm-project/pull/145175
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
