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, 19 Dec 2017 13:39:22 -0800 Vineet Gupta
wrote:
> > --- a/kernel/exit.c
> > +++ b/kernel/exit.c
> > @@ -1759,3 +1759,11 @@ long kernel_wait4(pid_t upid, int __user *stat_addr,
> > int options,
> > return -EFAULT;
> > }
> > #endif
> > +
> > +__weak void abort(void)
> > +{
> > +
On 12/12/2017 02:49 PM, Sudip Mukherjee wrote:
gcc toggle -fisolate-erroneous-paths-dereference (default at -O2
onwards) isolates faulty code paths such as null pointer access, divide
by zero etc. If gcc port doesnt implement __builtin_trap, an abort() is
generated which causes kernel link error.
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/09, Eugeniy Paltsev wrote:
> Set initial core pll output frequency on HSDK and AXS103 via
> "assigned-clock-rates" property in device tree.
> It will be applied at the core pll driver probing.
>
> Eugeniy Paltsev (4):
> ARC: [plat-hsdk]: Set initial core pll output frequency
> ARC: [pl
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
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 noreturn function or
__builtin_unreachable() keep us
