[PATCH] D32618: DWARF: Implementation of v5 string offsets table (.debug_str_offsets[.dwo] section)

[Adrian Prantl via Phabricator via llvm-commits]

aprantl added a comment.

In https://reviews.llvm.org/D32618#740265, @wolfgangp wrote:

> In https://reviews.llvm.org/D32618#740256, @aprantl wrote:
>
> > > Also, apologies for not handling Mach-O.
> >
> > Typically we try to do a best effort on all supported containers (ELF, Mach-O, COFF) when adding new features.
> >  Could you outline what is necessary there? Is it just coming up with a short-enough section name or is there more to it?
>
>
> That is probably it. Basically, the hardest part is just making string references unique to the unit (compile unit, type unit) and putting all the relocatable string references into the new section. Nothing that should be specific to the object file format. I can take a stab at it, it shouldn't take too long.


Thanks! I looked through my mail archive and found this text that I compiled for the dwarf mailing list last year about the various platforms' name limitations:

> I recommend adding the following non-normative text about Mach-O [1] (as used by OS X, iOS, ...):
> 
>   In the Mach-O object file format, debug info sections are located
>   in the __DEBUG segment. By convention, section names start with a
>   double underscore instead of the leading dot. Section names are
>   truncated to 16 characters. Since Mach-O linkers do not link the
>   debug information, there is no real use-case for the .dwo
>   sections.
>    
> 
> If I had to invent names for the .dwo sections I would replace the debug prefix with dwo. For example:
> 
>   1234567890123456             1234567890123456
>   .debug_str_offsets.dwo ->    __dwo_str_offset
>    
> 
> But, since no compiler implements DWO support for Mach-O (it is solving a problem that does not exist on the platform), I’m unsure whether we should standardize names at this point.
> 
> For COFF, which is used on Windows, the situation is confusing. I’ve been told that the COFF linker truncates section names after 8 characters. Still, apparently the file format can hold more than that and compilers like clang use the full ELF section names and this does not seem to be problem. My best guess is that this works because all of the DWARF 2 section names are unique after 8 characters. Other compilers like Microsoft’s Visual Studio don’t emit DWARF, but use their own CodeView debug file format. I’m unsure how to describe this situation in the text. Maybe we should pass.



- adrian


https://reviews.llvm.org/D32618