similar to: [RFC PATCH 01/11] Add basic support for gcc profiler instrumentation

On Thu, May 24, 2018 at 1:16 PM Steven Rostedt <rostedt at goodmis.org> wrote: > On Thu, 24 May 2018 13:40:24 +0200 > Petr Mladek <pmladek at suse.com> wrote: > > On Wed 2018-05-23 12:54:15, Thomas Garnier wrote: > > > When using -fPIE/PIC with function tracing, the compiler generates a > > > call through the GOT (call *__fentry__ at GOTPCREL). This

On Wed 2018-05-23 12:54:15, Thomas Garnier wrote: > When using -fPIE/PIC with function tracing, the compiler generates a > call through the GOT (call *__fentry__ at GOTPCREL). This instruction > takes 6 bytes instead of 5 on the usual relative call. > > If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte nop > so ftrace can handle the previous 5-bytes as before.

On Wed 2018-05-23 12:54:15, Thomas Garnier wrote: > When using -fPIE/PIC with function tracing, the compiler generates a > call through the GOT (call *__fentry__ at GOTPCREL). This instruction > takes 6 bytes instead of 5 on the usual relative call. > > If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte nop > so ftrace can handle the previous 5-bytes as before.

--- ../multipath-tools-0.2.8.1/klibc/klibc/arch/i386/MCONFIG 2004-07-20 10:51:42.000000000 +0200 +++ klibc/klibc/arch/i386/MCONFIG 2004-07-27 17:10:12.000000000 +0200 @@ -13,7 +13,7 @@ # them to be cdecl # REGPARM = -mregparm=3 -DREGPARM -gcc_major := $(shell $(CC) -v 2>&1 | awk '/gcc version/{print int($$3)}') +gcc_major := $(shell unset LANG;$(CC) -v 2>&1 | awk

On Thu, Oct 5, 2017 at 6:06 AM, Steven Rostedt <rostedt at goodmis.org> wrote: > On Wed, 4 Oct 2017 14:19:56 -0700 > Thomas Garnier <thgarnie at google.com> wrote: > >> When using -fPIE/PIC with function tracing, the compiler generates a >> call through the GOT (call *__fentry__ at GOTPCREL). This instruction >> takes 6 bytes instead of 5 on the usual

On Thu, Oct 5, 2017 at 6:06 AM, Steven Rostedt <rostedt at goodmis.org> wrote: > On Wed, 4 Oct 2017 14:19:56 -0700 > Thomas Garnier <thgarnie at google.com> wrote: > >> When using -fPIE/PIC with function tracing, the compiler generates a >> call through the GOT (call *__fentry__ at GOTPCREL). This instruction >> takes 6 bytes instead of 5 on the usual

From: Steven Rostedt (VMware) <rostedt at goodmis.org> In discussing a build failure on x86_32 due to the use of roundup() on a 64 bit number, I realized that there's no generic equivalent roundup_64(). It is implemented in two separate places in the kernel, but there really should be just one that all can use. Although the other implementations are a static inline function, this

?ukasz Daniluk reported that on a RHEL kernel that his machine would lock up after enabling function tracer. I asked him to bisect the functions within available_filter_functions, which he did and it came down to three: _paravirt_nop(), _paravirt_ident_32() and _paravirt_ident_64() It was found that this is only an issue when noreplace-paravirt is added to the kernel command line. This means

?ukasz Daniluk reported that on a RHEL kernel that his machine would lock up after enabling function tracer. I asked him to bisect the functions within available_filter_functions, which he did and it came down to three: _paravirt_nop(), _paravirt_ident_32() and _paravirt_ident_64() It was found that this is only an issue when noreplace-paravirt is added to the kernel command line. This means

On Thu, 23 May 2019 08:10:44 -0700 Linus Torvalds <torvalds at linux-foundation.org> wrote: > On Thu, May 23, 2019 at 7:00 AM Steven Rostedt <rostedt at goodmis.org> wrote: > > > > +# define roundup_64(x, y) ( \ > > +{ \ > > + typeof(y) __y = y;

When using -fPIE/PIC with function tracing, the compiler generates a call through the GOT (call *__fentry__ at GOTPCREL). This instruction takes 6 bytes instead of 5 on the usual relative call. With this change, function tracing supports 6 bytes on traceable function and can still replace relative calls on the ftrace assembly functions. Position Independent Executable (PIE) support will allow to

Hey, I was running some benchmarks (netserver/netperf) where the init script just launched the netserver and nothing else and was concerned to see the performance not up to par. This was an HVM guest running with PV drivers. If I compile the kernel without CONFIG_FUNCTION_TRACER it is much better - but it was my understanding that the tracing code does not impact the machine unless it is

Steven Rostedt <rostedt at goodmis.org> writes: > On Thu, 26 Jan 2023 18:01:14 +0100 > Petr Machata <petrm at nvidia.com> wrote: > >> + TP_printk("dev %s af %u src %pI4/%pI6c grp %pI4/%pI6c/%pM vid %u", >> + __get_str(dev), __entry->af, __entry->src4, __entry->src6, >> + __entry->grp4, __entry->grp6, __entry->grpmac,

On 2020-07-27 19:20, hpa at zytor.com wrote: > > I'm not so sure they have dealt with it in the sense of having it work on all architectures. *Most* of the problems are related to the shifting the arguments by one, which can cause a bunch of problems, especially if it means the arguments spill to memory. However, I have absolutely no idea how to correctly implement syscall(3) on s390

Hey folks, Here's a new spin of the pvops64 patch series. We didn't get that many comments from the last time, so it should be probably almost ready to get in. Heya! >From the last version, the most notable changes are: * consolidation of system.h, merging jeremy's comments about ordering concerns * consolidation of smp functions that goes through smp_ops. They're sharing

Hey folks, Here's a new spin of the pvops64 patch series. We didn't get that many comments from the last time, so it should be probably almost ready to get in. Heya! >From the last version, the most notable changes are: * consolidation of system.h, merging jeremy's comments about ordering concerns * consolidation of smp functions that goes through smp_ops. They're sharing

On Thu, 23 May 2019 09:51:29 -0700 Linus Torvalds <torvalds at linux-foundation.org> wrote: > On Thu, May 23, 2019 at 8:27 AM Steven Rostedt <rostedt at goodmis.org> wrote: > > > > I haven't yet tested this, but what about something like the following: > > So that at least handles the constant case that the normal "roundup()" > case also

On Fri, 15 Nov 2013 04:53:18 +0000 Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > .entry.text is a code area which is used for interrupt/syscall > entries, and there are many sensitive codes. > Thus, it is better to prohibit probing on all of such codes > instead of a part of that. > Since some symbols are already registered on kprobe blacklist, > this also

On Fri, 15 Nov 2013 04:53:18 +0000 Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > .entry.text is a code area which is used for interrupt/syscall > entries, and there are many sensitive codes. > Thus, it is better to prohibit probing on all of such codes > instead of a part of that. > Since some symbols are already registered on kprobe blacklist, > this also

Hi Qiao, On 24/07/13 08:23, Qiao Yang wrote: > Hi, > > I am trying to compile a simple program with Clang 3.3 on Linux and used -pg and -O2 option. The program would crash with segfault. Interestingly if I compile it with -pg option only it works. Do you have any idea why it crashes? And any workaround? > > $ cat myprog.c > int main() { > return 0; > } > > $