Russell King - ARM Linux wrote:
> [ ... ] this thread should probably die until some problem has actually
> been identified.
>
> If it ain't broke, don't fix.
Couldn't agree more. Happy Christmas!
cheers,
DaveK
On Tue, Dec 22, 2009 at 02:09:02PM +, Dave Korn wrote:
> Russell King - ARM Linux wrote:
> > On Mon, Dec 21, 2009 at 11:30:43AM -0800, Richard Henderson wrote:
> >> On 12/17/2009 10:17 AM, Russell King - ARM Linux wrote:
> >>> How is "size-optimal trap" defined?
> >> E.g. Sparc and MIPS have "t
Russell King - ARM Linux wrote:
> On Mon, Dec 21, 2009 at 11:30:43AM -0800, Richard Henderson wrote:
>> On 12/17/2009 10:17 AM, Russell King - ARM Linux wrote:
>>> How is "size-optimal trap" defined?
>> E.g. Sparc and MIPS have "tcc" instructions that trap based on the
>> condition codes, and so we
On 12/17/2009 06:17 PM, Richard Guenther wrote:
It shouldn't as *(int *)0 = 0; might trap. But if you want to be sure
use
__builtin_trap ();
instead for the whole sequence (the unreachable is implied then).
GCC choses a size-optimal trap representation for your target then.
Agree that it s
On Mon, Dec 21, 2009 at 11:30:43AM -0800, Richard Henderson wrote:
> On 12/17/2009 10:17 AM, Russell King - ARM Linux wrote:
>> How is "size-optimal trap" defined?
>
> E.g. Sparc and MIPS have "tcc" instructions that trap based on the
> condition codes, and so we eliminate the branch. That's the o
On 12/17/2009 10:17 AM, Russell King - ARM Linux wrote:
How is "size-optimal trap" defined?
E.g. Sparc and MIPS have "tcc" instructions that trap based on the
condition codes, and so we eliminate the branch. That's the only
optimization we apply with __builtin_trap.
Let me put it another way
On Thu, Dec 17, 2009 at 07:48:37PM +, Russell King - ARM Linux wrote:
> Given the lack of progress/bug reporting on ARM uclinux, the lack of
> platform support and the lack of configurations, my view is that there
> is no one actually using it. I know that I don't particularly take any
> care
On Thu, Dec 17, 2009 at 07:38:26PM +, Jamie Lokier wrote:
> Joe Buck wrote:
> > On Thu, Dec 17, 2009 at 11:06:13AM -0800, Russell King - ARM Linux wrote:
> > > On Thu, Dec 17, 2009 at 10:35:17AM -0800, Joe Buck wrote:
> > > > Besides, didn't I see a whole bunch of kernel security patches relate
Joe Buck wrote:
> On Thu, Dec 17, 2009 at 11:06:13AM -0800, Russell King - ARM Linux wrote:
> > On Thu, Dec 17, 2009 at 10:35:17AM -0800, Joe Buck wrote:
> > > Besides, didn't I see a whole bunch of kernel security patches related
> > > to null pointer dereferences lately? If page 0 can be mapped,
Joe Buck wrote:
On Thu, Dec 17, 2009 at 11:06:13AM -0800, Russell King - ARM Linux wrote:
On Thu, Dec 17, 2009 at 10:35:17AM -0800, Joe Buck wrote:
Besides, didn't I see a whole bunch of kernel security patches related
to null pointer dereferences lately? If page 0 can be mapped, you
suddenly
On Thu, Dec 17, 2009 at 11:14:01AM -0800, Joe Buck wrote:
> On Thu, Dec 17, 2009 at 11:06:13AM -0800, Russell King - ARM Linux wrote:
> > On Thu, Dec 17, 2009 at 10:35:17AM -0800, Joe Buck wrote:
> > > Besides, didn't I see a whole bunch of kernel security patches related
> > > to null pointer dere
On Thu, Dec 17, 2009 at 11:06:13AM -0800, Russell King - ARM Linux wrote:
> On Thu, Dec 17, 2009 at 10:35:17AM -0800, Joe Buck wrote:
> > Besides, didn't I see a whole bunch of kernel security patches related
> > to null pointer dereferences lately? If page 0 can be mapped, you
> > suddenly won't
On Thu, Dec 17, 2009 at 10:35:17AM -0800, Joe Buck wrote:
> Besides, didn't I see a whole bunch of kernel security patches related
> to null pointer dereferences lately? If page 0 can be mapped, you
> suddenly won't get your trap.
Page 0 can not be mapped on ARM kernels since the late 1990s, and
Russell King - ARM Linux wrote:
> Let me put it another way: I want this function to terminate with an
> explicit NULL pointer dereference in every case.
__builtin_trap cannot be used because the GCC manual says "The
mechanism used may vary from release to release so you should not rely
on any par
On Thu, Dec 17, 2009 at 10:17:18AM -0800, Russell King - ARM Linux wrote:
> > It shouldn't as *(int *)0 = 0; might trap. But if you want to be sure
> > use
> >__builtin_trap ();
> > instead for the whole sequence (the unreachable is implied then).
> > GCC choses a size-optimal trap representat
On Thu, Dec 17, 2009 at 06:17:11PM +0100, Richard Guenther wrote:
> On Thu, Dec 17, 2009 at 6:09 PM, David Daney
> wrote:
> > Jamie Lokier wrote:
> >>
> >> Uwe Kleine-König wrote:
> >>>
> >>> Use the new unreachable() macro instead of for(;;);
> >>> *(int *)0 = 0;
> >>> /* Avoid "
On Thu, Dec 17, 2009 at 6:09 PM, David Daney wrote:
> Jamie Lokier wrote:
>>
>> Uwe Kleine-König wrote:
>>>
>>> Use the new unreachable() macro instead of for(;;);
>>> *(int *)0 = 0;
>>> /* Avoid "noreturn function does return" */
>>> - for (;;);
>>> + unreachable();
>>
Jamie Lokier wrote:
Uwe Kleine-König wrote:
Use the new unreachable() macro instead of for(;;);
*(int *)0 = 0;
/* Avoid "noreturn function does return" */
- for (;;);
+ unreachable();
Will GCC-4.5 remove ("optimise away") the *(int *)0 = 0 because it
knows the branch o
18 matches
Mail list logo
