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

2018-04-10 Thread Segher Boessenkool
t it out. Tested on powerpc64-linux and on powerpc-ibm-aix7.2.0.0 . Segher --- From: Segher Boessenkool <seg...@kernel.crashing.org> Date: Thu, 5 Apr 2018 09:27:31 + Subject: [PATCH] rs6000: Enable -fasynchronous-unwind-tables by default To find out where on-entry register values liv

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

2018-04-05 Thread David Edelsohn
On Thu, Apr 5, 2018 at 5:50 AM, Jakub Jelinek wrote: > On Thu, Apr 05, 2018 at 09:45:54AM +, 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

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

2018-04-05 Thread Jakub Jelinek
On Thu, Apr 05, 2018 at 05:08:36AM -0500, Segher Boessenkool wrote: > On Thu, Apr 05, 2018 at 11:50:38AM +0200, Jakub Jelinek wrote: > > On Thu, Apr 05, 2018 at 09:45:54AM +, Segher Boessenkool wrote: > > > To find out where on-entry register values live at any point in a > > > program, GDB

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

2018-04-05 Thread Jakub Jelinek
On Thu, Apr 05, 2018 at 09:45:54AM +, 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

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

2018-04-05 Thread Segher Boessenkool
On Thu, Apr 05, 2018 at 11:50:38AM +0200, Jakub Jelinek wrote: > On Thu, Apr 05, 2018 at 09:45:54AM +, 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

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

2018-04-05 Thread Segher Boessenkool
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