On Thu, Nov 19, 2020 at 9:05 AM Alexei Starovoitov
wrote:
>
> On Thu, Nov 19, 2020 at 6:59 AM Steven Rostedt wrote:
> > Linux obviously
> > supports multiple architectures (more than any other OS), but it is pretty
> > stuck to gcc as a compiler (with LLVM just starting to work too).
> >
> > We
On Thu, Nov 19, 2020 at 05:42:34PM +, David Laight wrote:
> From: Segher Boessenkool
> > Sent: 19 November 2020 16:35
> > I just meant "valid C language code as defined by the standards". Many
> > people want all UB to just go away, while that is *impossible* to do for
> > many compilers: for
From: Segher Boessenkool
> Sent: 19 November 2020 16:35
...
> I just meant "valid C language code as defined by the standards". Many
> people want all UB to just go away, while that is *impossible* to do for
> many compilers: for example where different architectures or different
> ABIs have
On Thu, 19 Nov 2020 09:04:57 -0800
Alexei Starovoitov wrote:
> On Thu, Nov 19, 2020 at 6:59 AM Steven Rostedt wrote:
> > Linux obviously
> > supports multiple architectures (more than any other OS), but it is pretty
> > stuck to gcc as a compiler (with LLVM just starting to work too).
> >
> >
On Thu, Nov 19, 2020 at 6:59 AM Steven Rostedt wrote:
> Linux obviously
> supports multiple architectures (more than any other OS), but it is pretty
> stuck to gcc as a compiler (with LLVM just starting to work too).
>
> We are fine with being stuck to a compiler if it gives us what we want.
I
On Thu, Nov 19, 2020 at 09:59:51AM -0500, Steven Rostedt wrote:
> On Thu, 19 Nov 2020 08:37:35 -0600
> Segher Boessenkool wrote:
> > > Note that we have a fairly extensive tradition of defining away UB with
> > > language extentions, -fno-strict-overflow, -fno-strict-aliasing,
> >
> > These
On Thu, 19 Nov 2020 08:37:35 -0600
Segher Boessenkool wrote:
> > Note that we have a fairly extensive tradition of defining away UB with
> > language extentions, -fno-strict-overflow, -fno-strict-aliasing,
>
> These are options to make a large swath of not correct C programs
> compile (and
On Thu, Nov 19, 2020 at 09:36:48AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 18, 2020 at 01:11:27PM -0600, Segher Boessenkool wrote:
> > Calling this via a different declared function type is undefined
> > behaviour, but that is independent of how the function is *defined*.
> > Your program can
On Wed, Nov 18, 2020 at 01:11:27PM -0600, Segher Boessenkool wrote:
> Calling this via a different declared function type is undefined
> behaviour, but that is independent of how the function is *defined*.
> Your program can make ducks appear from your nose even if that function
> is never called,
On Wed, Nov 18, 2020 at 01:48:37PM -0600, Segher Boessenkool wrote:
> If you have at most four or so args, what you wnat to do will work on
> all systems the kernel currently supports, as far as I can tell. It
> is not valid C, and none of the compilers have an extension for this
> either. But
On Wed, 18 Nov 2020 13:48:37 -0600
Segher Boessenkool wrote:
> > With it_func being the func from the struct tracepoint_func, which is a
> > void pointer, it is typecast to the function that is defined by the
> > tracepoint. args is defined as the arguments that match the proto.
>
> If you
On Wed, 18 Nov 2020 11:46:02 -0800
Alexei Starovoitov wrote:
> On Wed, Nov 18, 2020 at 6:22 AM Steven Rostedt wrote:
> >
> > Thus, all functions will be non-variadic in these cases.
>
> That's not the only case where it will blow up.
> Try this on sparc:
> struct foo {
> int a;
> };
>
>
On Wed, Nov 18, 2020 at 02:33:43PM -0500, Steven Rostedt wrote:
> On Wed, 18 Nov 2020 13:11:27 -0600
> Segher Boessenkool wrote:
>
> > Calling this via a different declared function type is undefined
> > behaviour, but that is independent of how the function is *defined*.
> > Your program can
On Wed, Nov 18, 2020 at 6:22 AM Steven Rostedt wrote:
>
> Thus, all functions will be non-variadic in these cases.
That's not the only case where it will blow up.
Try this on sparc:
struct foo {
int a;
};
struct foo foo_struct(void) {
struct foo f = {};
return f;
}
int foo_int(void) {
return 0;
On Wed, 18 Nov 2020 13:11:27 -0600
Segher Boessenkool wrote:
> Calling this via a different declared function type is undefined
> behaviour, but that is independent of how the function is *defined*.
> Your program can make ducks appear from your nose even if that function
> is never called, if
On Wed, Nov 18, 2020 at 01:58:23PM -0500, Steven Rostedt wrote:
> I wonder if we should define on all architectures a void void_stub(void),
> in assembly, that just does a return, an not worry about gcc messing up the
> creation of the stub function.
>
> On x86_64:
>
> GLOBAL(void_stub)
>
On Wed, Nov 18, 2020 at 07:31:50PM +0100, Florian Weimer wrote:
> * Segher Boessenkool:
>
> > On Wed, Nov 18, 2020 at 12:17:30PM -0500, Steven Rostedt wrote:
> >> I could change the stub from (void) to () if that would be better.
> >
> > Don't? In a function definition they mean exactly the same
On Wed, 18 Nov 2020 13:58:23 -0500
Steven Rostedt wrote:
> an not worry about gcc
or LLVM, or whatever is used to build the kernel.
-- Steve
On Wed, 18 Nov 2020 19:31:50 +0100
Florian Weimer wrote:
> * Segher Boessenkool:
>
> > On Wed, Nov 18, 2020 at 12:17:30PM -0500, Steven Rostedt wrote:
> >> I could change the stub from (void) to () if that would be better.
> >
> > Don't? In a function definition they mean exactly the same
* Segher Boessenkool:
> On Wed, Nov 18, 2020 at 12:17:30PM -0500, Steven Rostedt wrote:
>> I could change the stub from (void) to () if that would be better.
>
> Don't? In a function definition they mean exactly the same thing (and
> the kernel uses (void) everywhere else, which many people find
On Wed, Nov 18, 2020 at 12:17:30PM -0500, Steven Rostedt wrote:
> I could change the stub from (void) to () if that would be better.
Don't? In a function definition they mean exactly the same thing (and
the kernel uses (void) everywhere else, which many people find clearer).
In a function
On Wed, 18 Nov 2020 08:50:37 -0800
Nick Desaulniers wrote:
> On Wed, Nov 18, 2020 at 5:23 AM Peter Zijlstra wrote:
> >
> > On Tue, Nov 17, 2020 at 03:34:51PM -0500, Steven Rostedt wrote:
> >
> > > > > Since all tracepoints callbacks have at least one parameter (__data),
> > > > > we
> > > >
On Wed, Nov 18, 2020 at 5:23 AM Peter Zijlstra wrote:
>
> On Tue, Nov 17, 2020 at 03:34:51PM -0500, Steven Rostedt wrote:
>
> > > > Since all tracepoints callbacks have at least one parameter (__data), we
> > > > could declare tp_stub_func as:
> > > >
> > > > static void tp_stub_func(void *data,
From: Mathieu Desnoyers
> Sent: 18 November 2020 16:01
...
> > If it is already done elsewhere in the kernel, then I will call this
> > precedence, and keep the original version.
>
> It works for me. Bonus points if you can document in a comment that this
> trick depends on the cdecl calling
- On Nov 18, 2020, at 9:02 AM, rostedt rost...@goodmis.org wrote:
> On Wed, 18 Nov 2020 14:21:36 +0100
> Peter Zijlstra wrote:
>
>> I think that as long as the function is completely empty (it never
>> touches any of the arguments) this should work in practise.
>>
>> That is:
>>
>> void
On Wed, 18 Nov 2020 14:59:29 +0100
Florian Weimer wrote:
> * Peter Zijlstra:
>
> > I think that as long as the function is completely empty (it never
> > touches any of the arguments) this should work in practise.
> >
> > That is:
> >
> > void tp_nop_func(void) { }
> >
> > can be used as an
* Peter Zijlstra:
>> The default Linux calling conventions are all of the cdecl family,
>> where the caller pops the argument off the stack. You didn't quote
>> enough to context to tell whether other calling conventions matter in
>> your case.
>
> This is strictly in-kernel, and I think we're
On Wed, Nov 18, 2020 at 02:59:29PM +0100, Florian Weimer wrote:
> * Peter Zijlstra:
>
> > I think that as long as the function is completely empty (it never
> > touches any of the arguments) this should work in practise.
> >
> > That is:
> >
> > void tp_nop_func(void) { }
> >
> > can be used as
On Wed, 18 Nov 2020 14:21:36 +0100
Peter Zijlstra wrote:
> I think that as long as the function is completely empty (it never
> touches any of the arguments) this should work in practise.
>
> That is:
>
> void tp_nop_func(void) { }
My original version (the OP of this thread) had this:
* Peter Zijlstra:
> I think that as long as the function is completely empty (it never
> touches any of the arguments) this should work in practise.
>
> That is:
>
> void tp_nop_func(void) { }
>
> can be used as an argument to any function pointer that has a void
> return. In fact, I already do
On Tue, Nov 17, 2020 at 03:34:51PM -0500, Steven Rostedt wrote:
> > > Since all tracepoints callbacks have at least one parameter (__data), we
> > > could declare tp_stub_func as:
> > >
> > > static void tp_stub_func(void *data, ...)
> > > {
> > > return;
> > > }
> > >
> > > And now C knows
31 matches
Mail list logo
