[PATCH] rs6000: Enable -fasynchronous-unwind-tables by default

David Edelsohn dje.gcc@gmail.com
Thu Apr 5 17:07:00 GMT 2018


On Thu, Apr 5, 2018 at 5:50 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Apr 05, 2018 at 09:45:54AM +0000, Segher Boessenkool wrote:
>> To find out where on-entry register values live at any point in a
>> program, GDB currently tries to parse to parse the executable code.
>> This does not work very well, for example it gets confused if some
>> accesses to the stack use the frame pointer (r31) and some use the
>> stack pointer (r1).  A symptom is that backtraces can be cut short.
>>
>> This patch enables -fasynchronous-unwind-tables by default for rs6000,
>> which causes us to emit DWARF unwind tables for all functions, solving
>> these problems.
>>
>> This not do anything for sub-targets without DWARF.
>>
>> It increases executable size, but only modestly, and does not change
>> memory use, only the disk image.
>>
>> Various other targets already do this (x86, s390, tile*).
>
> aarch64-linux* too (since r258871).
>
>> Tested on powerpc64-linux {-m32,-m64}.  David, I'd like to commit this
>> to current trunk; does that seem too dangerous to you?
>
> If David is ok with it, it is fine for trunk even in stage4.

I don't have a fundamental objection.  AIX does use DWARF EH. I'm not
worried about the EH processing itself, but this may trigger paths in
dwarf2out, etc. that aren't prepared for AIX XCOFF. I'm concerned that
it may assume ELF section or insert additional section names or
generally output code that is incompatible with the AIX assembler or
linker.

Also, AIX XCOFF does not have a special section for DWARF EH
information, so it is stuffed in data section and will increase the
memory image size.

We need to test it on AIX and see what happens.

- David



More information about the Gcc-patches mailing list