On Wed, Apr 11, 2018 at 12:08:51PM +0200, Arnd Bergmann wrote:
> On Wed, Apr 11, 2018 at 11:54 AM, James Hogan wrote:
> > On Wed, Apr 11, 2018 at 09:30:56AM +0200, Arnd Bergmann wrote:
> >> On Wed, Apr 11, 2018 at 12:48 AM, James Hogan wrote:
> >> > Before I forward port those patches to add .ins
On Wed, Apr 11, 2018 at 11:54 AM, James Hogan wrote:
> On Wed, Apr 11, 2018 at 09:30:56AM +0200, Arnd Bergmann wrote:
>> On Wed, Apr 11, 2018 at 12:48 AM, James Hogan wrote:
>> > Before I forward port those patches to add .insn for MIPS, is that sort
>> > of approach (an arch specific asm/compile
On Wed, Apr 11, 2018 at 09:30:56AM +0200, Arnd Bergmann wrote:
> On Wed, Apr 11, 2018 at 12:48 AM, James Hogan wrote:
> > Before I forward port those patches to add .insn for MIPS, is that sort
> > of approach (an arch specific asm/compiler-gcc.h to allow MIPS to
> > override barrier_before_unreac
On Wed, Apr 11, 2018 at 12:48 AM, James Hogan wrote:
> Hi Arnd,
>
> On Tue, Dec 19, 2017 at 12:39:33PM +0100, Arnd Bergmann wrote:
>> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
>> index 5d595cfdb2c4..66cfdad68f7e 100644
>> --- a/include/linux/compiler-gcc.h
>> +++ b/i
Hi Arnd,
On Tue, Dec 19, 2017 at 12:39:33PM +0100, Arnd Bergmann wrote:
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 5d595cfdb2c4..66cfdad68f7e 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -205,6 +205,15 @@
> #endif
>
On 02/07/2018 05:20 PM, Vineet Gupta wrote:
Didn't do ;)
Is Arnd's patch good to merge or do we need a fixup?
From: Arnd Bergmann
Subject: bug.h: work around GCC PR82365 in BUG()
Looking at functions with large stack frames across all architectures led
me discovering that BUG() suffers fro
On 02/07/2018 04:01 PM, Andrew Morton wrote:
On Wed, 20 Dec 2017 12:29:02 -0800 Vineet Gupta
wrote:
On 12/20/2017 12:12 PM, Arnd Bergmann wrote:
Sorry, I didn't realize we are missing the stack trace now which you removed
from the patch - why ? Did u intend to reduce inline generated code fo
On 02/07/2018 04:01 PM, Andrew Morton wrote:
On Wed, 20 Dec 2017 12:29:02 -0800 Vineet Gupta
wrote:
On 12/20/2017 12:12 PM, Arnd Bergmann wrote:
Sorry, I didn't realize we are missing the stack trace now which you removed
from the patch - why ? Did u intend to reduce inline generated code fo
On Wed, 20 Dec 2017 12:29:02 -0800 Vineet Gupta
wrote:
> On 12/20/2017 12:12 PM, Arnd Bergmann wrote:
> >> Sorry, I didn't realize we are missing the stack trace now which you
> >> removed
> >> from the patch - why ? Did u intend to reduce inline generated code for the
> >> stack dump calls - w
On 12/20/2017 12:12 PM, Arnd Bergmann wrote:
Sorry, I didn't realize we are missing the stack trace now which you removed
from the patch - why ? Did u intend to reduce inline generated code for the
stack dump calls - which sounds like a great idea. But it would only work
for the synchronous abort
On Wed, Dec 20, 2017 at 7:52 PM, Vineet Gupta
wrote:
> On 12/20/2017 01:01 AM, Arnd Bergmann wrote:
>>
>> On Tue, Dec 19, 2017 at 11:38 PM, Vineet Gupta
>> wrote:
>>>
>>> On 12/19/2017 12:13 PM, Arnd Bergmann wrote:
> I suppose BUG() implies "dead end" like semantics - which AR
On 12/20/2017 01:01 AM, Arnd Bergmann wrote:
On Tue, Dec 19, 2017 at 11:38 PM, Vineet Gupta
wrote:
On 12/19/2017 12:13 PM, Arnd Bergmann wrote:
I suppose BUG() implies "dead end" like semantics - which ARC was lacking
before ?
Correct. Using __builtin_trap() here avoids the 'control reach
On Tue, Dec 19, 2017 at 11:38 PM, Vineet Gupta
wrote:
> On 12/19/2017 12:13 PM, Arnd Bergmann wrote:
>>
>>
>>> I suppose BUG() implies "dead end" like semantics - which ARC was lacking
>>> before ?
>>
>> Correct. Using __builtin_trap() here avoids the 'control reaches end of
>> non-void
>> functio
On 12/19/2017 12:13 PM, Arnd Bergmann wrote:
I suppose BUG() implies "dead end" like semantics - which ARC was lacking
before ?
Correct. Using __builtin_trap() here avoids the 'control reaches end of non-void
function' warnings, but then makes us run into the stack size problem that
I work aro
On Tue, Dec 19, 2017 at 5:57 PM, Vineet Gupta
wrote:
> On 12/19/2017 03:41 AM, Arnd Bergmann wrote:
>> In case of ARC and CRIS, it turns out that the BUG() implementation
>> actually does return (or at least the compiler thinks it does), resulting
>> in lots of warnings about uninitialized variab
On 12/19/2017 03:41 AM, Arnd Bergmann wrote:
Looking at functions with large stack frames across all architectures
led me discovering that BUG() suffers from the same problem as
fortify_panic(), which I've added a workaround for already. In short,
variables that go out of scope by calling a noret
Hi Arnd,
On Tue, Dec 19, 2017 at 12:39 PM, Arnd Bergmann wrote:
> The name barrier_before_unreachable() is a bit suboptimal here,
> as it fails to describe the fact that it is needed for both
> __builtin_unreachable() and for calling noreturn functions. Any other
> suggestions would be welcome h
17 matches
Mail list logo
