================
@@ -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:
> Probably unlikely, but could the truncation change in the future to a
> different size?
The truncation will always be 8 bytes, because that's how much space the
section name has in the PE/COFF section header - it's basically a `char
name[8]` field. For longer names, the linker has to write the section name into
the string table and set the name in the section header to `/n` where `n` is
the offset in the string table.
> Could we just check the section_type and prefix and issue a warning saying
> "unrecognized section, possibly got truncated"?
That could be an additional diagnostic for unknown DWARF sections (should
probably be there for other object files as well). If the section name is 8
bytes, however, we can be sure this is from someone using link.exe.
As an extension, this could be present for `.lldbformatters` and
`.lldbsummaries` as well. In this specific case, the matching could also
consider `.lldbfor` and `.lldbsum`, because there are only two.
> Do we need the `size == 8` and `isLower` checks here?
We need the size check, but I removed the isLower check, because the indicator
for DWARF is `.debug_`.
https://github.com/llvm/llvm-project/pull/145175
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
