[PATCH] D29719: [MC] Accept and print a numeric value as an ELF section header's type

Simon Atanasyan via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 8 07:21:07 PST 2017


On Sun, Feb 26, 2017 at 10:39 PM, Rafael Avila de Espindola
<rafael.espindola at gmail.com> wrote:
> Simon Atanasyan <simon at atanasyan.com> writes:
>
>> Agreed.
>>
>> But there is a bug which needs to e fixed - on MIPS all .debug_*
>> sections with DWARF data should have the SHT_MIPS_DWARF section type
>> to differentiate them from sections with the same name but contain
>> non-DWARF debug information.
>> https://reviews.llvm.org/D29789.
>>
>> If I just assign the SHT_MIPS_DWARF to such sections, the MCSectionELF
>> will print `.section .debug_info,"",@`. It looks even more odd than
>> `.section .debug_info,"", at 0x7000001e`.
>
> Is there any reason why we (and gas) can't have a @mips_dwarf?

There is no reason prevent introducing a @mips_dwarf except one --
it's a long story while the bug needs to be fixed soon. In fact gas
and other GNU tools do not require a @mips_dwarf at all because they
use a workaround for .debug_* sections. These tools convert @progbits
to SHT_MIPS_DWARF flag and vice versa for .debug_* sections when
parsing / printing assembly.

I can implement a new a @mips_dwarf in the separate patch D29789 where
I set a correct SHT_MIPS_DWARF for .debug_*. But I still think that
printing a hex value for unknown/unexpected section type in the
`MCSectionELF::PrintSwitchToSection` routine is a good feature because
now we emit just "@" in that case and get an asm file that cannot be
parsed by llvm-mc.

-- 
Simon Atanasyan


More information about the llvm-commits mailing list