ode definitively makes sense and this
approach looks like it will help make the build-time test I have in mind
for gcov-kernel easier to implement.
As such, for all 3 patches (not sure if it makes a difference seeing
that this has already landed in linux-next):
Acked-by: Peter Oberparleiter
Rega
d in GCOV support.
>
> Link: https://reviews.llvm.org/rGcdd683b516d147925212724b09ec6fb792a40041
> Link: https://reviews.llvm.org/rG13a633b438b6500ecad9e4f936ebadf3411d0f44
> Suggested-by: Nathan Chancellor
> Signed-off-by: Nick Desaulniers
Acked-by: Peter Oberparleiter
--
table
since it's cleaned up again with patch 2).
Acked-by: Peter Oberparleiter
That said, I'm currently thinking of adding a compile time check that
performs a dry-run gcov_info => gcda conversion in user space to detect
these kind of issues before kernels fail unpredictably [1].
On 11.03.2021 19:38, Linus Torvalds wrote:
> On Thu, Mar 11, 2021 at 5:07 AM Peter Oberparleiter
> wrote:
>>
>> This patch adds a compile-time check to ensure that the kernel's version
>> of struct gcov_info has the same length as the one used by GCC as
>> deter
e number of run-time failures when using gcov kernel support
with new GCC versions that include updates to struct gcov_info.
Tested with various GCC versions between 4.9 and 10, and also Clang 11.
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891288
Signed-off-by: Peter Oberparleit
RS now,
> since we really do want CONSTRUCTORS, just not kernel binary
> ones.
>
> Signed-off-by: Johannes Berg
Looks good+nicer than v1 to me!
I also tested this patch on s390 and can confirm that it doesn't break
gcov-kernel there.
Reviewed-by: Peter Oberparleiter
Andrew
On 20.01.2021 17:09, Johannes Berg wrote:
> On Wed, 2021-01-20 at 17:07 +0100, Peter Oberparleiter wrote:
>
>> Do you expect other users for these new config symbols?
>
> Probably not.
>
>> If not it seems
>> to me that the goal of enabling module constructors
ng ever appears in /sys/kernel/debug/gcov/ (apart
> from the reset file), and with it we get the files and they work.
>
> I have no idea which tree this might go through, any suggestions?
So far Andrew Morton was kind enough to pick up gcov-kernel related
changes, so that route might be an option.
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
rc'
> not described in 'gcov_info_add'
> kernel/gcov/gcc_4_7.c:238: warning: Excess function parameter 'dest'
> description in 'gcov_info_add'
> kernel/gcov/gcc_4_7.c:238: warning: Excess function parameter 'source'
> descripti
: Remove old GCC 3.4 support")
> but that was for GCC 4.8 and this is for GCC 4.9.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/427
> Signed-off-by: Nick Desaulniers
Looks good, thanks!
Reviewed-by: Peter Oberparleiter
Andrew, could you pick this up via you
fig. You need to
remove the "bool" line and the "help" lines.
Before sending another version please test it to make sure that it does
not produce a prompt.
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
V_PROFILE_ALL
>>> larger and run slower. Also be sure to exclude files from profiling
>>> which are not linked to the kernel image to prevent linker errors.
>>>
>>> +config GCOV_PROFILE_PREREQS
>>> + bool "Profile Kernel for prereqs"
>>> + depends on GCOV_KERNEL
>>> + depends on !COMPILE_TEST
>>> + def_bool y if GCOV_KERNEL && !COMPILE_TEST
>>> + help
>>> + This options activates profiling for the specified kernel modules.
>>> +
>>> + When some modules need Gcov data, enable this config, then
>>> configure
>>> + with gcov on the corresponding modules,The directories or files of
>>> + these modules will be added profiling flags after kernel compile.
>>> +
>>> endmenu
>>> --
>>> 2.17.1
>>>
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
(Adding GCC's gcov maintainer Martin Liška)
On 10.09.2020 21:18, Linus Torvalds wrote:
> On Thu, Sep 10, 2020 at 5:52 AM Peter Oberparleiter
> wrote:
>>
>> Fix this by updating the in-kernel GCOV_COUNTERS value. Also re-enable
>> config GCOV_KERNEL for use with GCC 1
On 10.09.2020 23:49, David Laight wrote:
> I was wondering what happens if files compiled with different
> versions of gcc get linked together?
This is not supported by GCC. At runtime libgcov will reject all data
from object files compiled with a different GCC version.
--
Peter Oberpar
ssfully tested it with kernel 5.9-rc4 on s390 using GCC 10.1.1
and also with GCC 9.1.1 to see that it didn't break support for previous
GCC versions. In both cases there were no kernel panics and gcov worked
fine.
Could you try this patch to see if it also fixes the problem in your
environment?
ompile.
>> +
Replace the portion above with these lines:
config GCOV_PROFILE_PREREQS
def_bool y if GCOV_KERNEL && !COMPILE_TEST
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
+ If unsure, say N.
What reason is there for a user to manually set this to N? In my opinion
the only use case where this symbol makes sense is as an automatic
config symbol that can be used by other symbols that enable specific
GCOV profiling sites via a "depends" relation. The PREREQ symbol
indicates that is is ok to provide the manual choice of enabling such
profiling.
> +
> choice
> prompt "Specify GCOV format"
> depends on GCOV_KERNEL
>
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
!COMPILE_TEST
default n
There's no need to add GCOV_KERNEL_ALL here since that is about a user
choice ("I want all code compiled with profiling") vs. this new symbol
which is about an ability ("all prereqs for enabling profiling in
specific directories are met).
> +
> choice
> prompt "Specify GCOV format"
> depends on GCOV_KERNEL
>
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
This options activates profiling for the specified kernel modules.
> +
> + If unsure, say N.
> +
> + When some modules need Gcov data, enable this config, then configure
> + with gcov on the corresponding modules configs.The directories or files
> + of these modules will be added profiling flags after kernel compile.
> +
> choice
> prompt "Specify GCOV format"
> depends on GCOV_KERNEL
>
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
On 08.10.2019 18:08, Qian Cai wrote:
> On Tue, 2019-10-08 at 14:56 +0200, Christian Borntraeger wrote:
>> Adding Peter Oberparleiter.
>> Peter, can you have a look?
>>
>> On 08.10.19 10:27, Michal Hocko wrote:
>>> On Tue 08-10-19 09:43:57, Petr Mladek wrote:
>
itute such strncmp.
>
> Signed-off-by: Chuhong Yuan
Looks sane!
Acked-by: Peter Oberparleiter
> ---
> Changes in v2:
> - Revise the description.
>
> kernel/gcov/fs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/gcov/fs.c b/kernel/gco
3. Unload a module, then reset all coverage data by writing to
/sys/kernel/debug/gcov/reset.
Expectation: all coverage files associated with the module are
removed from debugfs.
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
gt; 1 file changed, 14 insertions(+), 4 deletions(-)
Reviewed-by: Peter Oberparleiter
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
f (info)
> + list_del(&info->head);
The if-clause can be removed since @info is always non-NULL.
[...]
> +static struct gcov_fn_info *gcov_fn_info_dup(struct gcov_fn_info *fn)
> +{
> + size_t cv_size; /* counter values size */
> +
This empty line should be removed.
[...]
Rest looks good! With these minor changes applied:
Reviewed-by: Peter Oberparleiter
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
s
> Signed-off-by: Tri Vo
> Tested-by: Trilok Soni
> Tested-by: Prasad Sodagudi
> Tested-by: Tri Vo
> ---
Looks good!
Reviewed-by: Peter Oberparleiter
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
is never needed.
>
> Cc: Peter Oberparleiter
> Signed-off-by: Greg Kroah-Hartman
> ---
> kernel/gcov/fs.c | 22 ++
> 1 file changed, 2 insertions(+), 20 deletions(-)
Acked-by: Peter Oberparleiter
Compile test was successful, but the patch introduces a com
et
> + * @info: profiling data set
> + */
> +void gcov_info_unlink(struct gcov_info *prev, struct gcov_info *info)
> +{
> + if (prev)
> + list_del(&prev->head);
This is incorrect - gcov_info_unlink should remove info from the list,
not its predecessor prev.
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
*fn, *tmp;
> +
> + dup = kmemdup(info, sizeof(*dup), GFP_KERNEL);
> + if (!dup)
> + return NULL;
> + INIT_LIST_HEAD(&dup->head);
> + INIT_LIST_HEAD(&dup->functions);
> + dup->filename = kstrdup(info->filename, GFP_KERNEL);
To be consistent, please also check for a failed allocation here.
> +
> + list_for_each_entry_safe(fn, tmp, &info->functions, head) {
It should not be necessary to use the _safe variant here as
info->functions is not modified during traversal.
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
e.c b/kernel/gcov/gcc_base.c
> new file mode 100644
> index ..823565bcf9bf
> --- /dev/null
> +++ b/kernel/gcov/gcc_base.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include
> +#include
linux/export.h should be included for the EXPORT_SYMBOL() macro.
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
suggestions on patch improvements that I'll post
in separate e-mails.
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
ruct_size(instance, entry, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Looks sane.
Reviewed-by: Peter Oberparleiter
Andrew, could you pick this patch up?
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
On 11.10.2018 12:37, Greg KH wrote:
> On Thu, Oct 11, 2018 at 08:58:49PM +1100, Stephen Rothwell wrote:
>> On Thu, 11 Oct 2018 09:44:36 +0200 Peter Oberparleiter
>> wrote:
>>> On 11.10.2018 02:48, Stephen Rothwell wrote:
>>>> OK, I have been carrying this &
/13/367
but didn't get a response. I guess I should have reposted sooner. But
before I do that:
Arnd: Is this something that you can pick up or should I include someone
else?
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
Rothwell
Tested-by: Stephen Rothwell
Signed-off-by: Peter Oberparleiter
---
include/asm-generic/vmlinux.lds.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index b4d74b1c1e1d..d7701d466b60 100644
--- a/i
pt, resulting in references between discarded and
non-discarded sections.
Since destructors are not used in the Linux kernel, fix this by
discarding these additional sections.
Reported-by: Arnd Bergmann
Reported-by: Greentime Hu
Tested-by: Masami Hiramatsu
Signed-off-by: Peter Oberparleite
hese fixes?
Peter Oberparleiter (2):
vmlinux.lds.h: Fix incomplete .text.exit discards
vmlinux.lds.h: Fix linker warnings about orphan .LPBX sections
arch/arm/kernel/vmlinux.lds.h | 2 ++
include/asm-generic/vmlinux.lds.h | 6 +++---
2 files changed, 5 insertions(+), 3 deletions(-)
--
2.17.0
On 08.09.2018 05:57, Masami Hiramatsu wrote:
> On Fri, 7 Sep 2018 14:50:59 +0200
> Peter Oberparleiter wrote:
>
>> On 06.09.2018 18:42, Masami Hiramatsu wrote:
>>> Peter Oberparleiter wrote:
>>>> I've attached a quick fix that should address both pr
On 06.09.2018 18:42, Masami Hiramatsu wrote:
> Peter Oberparleiter wrote:
>> I've attached a quick fix that should address both problems. I'd
>> appreciate if this patch could get some testing before I post proper fix
>> patches.
>
> Hmm, I'm still not a
\
MEM_DISCARD(exit.data*) \
MEM_DISCARD(exit.rodata*)
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
would be to blacklist
"CONFIG_GCOV_FORMAT_3_4=y" when using GCC >3.4.
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
>
> If you down-grade your compiler GCC 4.7 or older, oldconfig/syncconfig
> will display a prompt for the choice because GCOV_FORMAT_3_4 becomes
> visible as a new symbol.
Looks sane to me.
Acked-by: Peter Oberparleiter
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
as
virtual files in debugfs, and not in the kernel source tree. What source
of .gcda files would be covered by this .gitignore change?
>>
>> #
>> # Top-level generic files
>> --
>> 2.7.4
>>
--
Peter Oberparleiter
Linux on z Systems Development - IBM Germany
.2016 13:52, Peter Oberparleiter wrote:
> On 24.11.2016 13:46, Martin Liška wrote:
>> On 11/09/2016 10:21 AM, Peter Oberparleiter wrote:
>>> On 31.10.2016 10:35, Martin Liška wrote:
>>>> Starting from GCC 7.1, __gcov_exit is a new symbol expected
>>>> to b
On 24.11.2016 13:46, Martin Liška wrote:
> On 11/09/2016 10:21 AM, Peter Oberparleiter wrote:
>> On 31.10.2016 10:35, Martin Liška wrote:
>>> Starting from GCC 7.1, __gcov_exit is a new symbol expected
>>> to be implemented in a profiling runtime.
>>
>>
our patches inline instead of as attachment
as that helps quoting them in replies. See also
linux/Documentation/SubmittingPatches.
--
Peter Oberparleiter
Linux on z Systems Development - IBM Germany
th IS_ENABLED() safely.
>
> Signed-off-by: Masahiro Yamada
Acked-by: Peter Oberparleiter
> ---
>
> arch/mips/include/asm/page.h | 4 ++--
> arch/s390/kernel/setup.c | 6 ++
> arch/x86/mm/kaslr.c | 2 +-
> 3 files changed, 5 insertions(+), 7 deletions(
version >= 6"
Thanks for pointing this out - I completely missed that this was lost
between v2 and v3 of the patch. Should we re-post or can this be fixed
another way?
--
Peter Oberparleiter
Linux on z Systems Development - IBM Germany
On 01.07.2016 15:09, Florian Meier wrote:
> Added support for gcc version >= 6 in gcov.
>
> Signed-off-by: Florian Meier
Looks good, thanks! Tested successfully with gcc 4.8.5 and gcc 6.1.0.
Andrew, could you pick this change up via your tree?
Reviewed-by: Peter Oberparleiter
Test
gt; #elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
> #define GCOV_COUNTERS 9
>
Content looks good but the patch doesn't apply due to whitespace issues.
Could you send a version with the tabs remaining intact? Also a slightly
more verbose patch message (similar to the one of the original patch)
would be helpful.
--
Peter Oberparleiter
Linux on z Systems Development - IBM Germany
#if __GNUC__ == 6
> +#define GCOV_COUNTERS 10
> +#elif __GNUC__ == 5 && __GNUC_MINOR__ >= 1
> #define GCOV_COUNTERS 10
> #elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
> #define GCOV_COUNTERS 9
>
> Regards
> Florian Meier
>
--
Peter Oberparleiter
Linux on z Systems Development - IBM Germany
gt; the warnings whenever GCOV is enabled. Most users don't enable GCOV,
> and based on a prior patch, it is now also disabled for 'allmodconfig'
> builds, so there should be no downsides of doing this.
>
> Signed-off-by: Arnd Bergmann
Sounds sane.
Acked-by: Peter Obe
in production are
> affected now.
>
> Signed-off-by: Arnd Bergmann
-fno-tree-loop-im seems to have been available for long enough in GCC
(starting with GCC4) to make this part of the default gcov compile flags.
Acked-by: Peter Oberparleiter
> ---
> Makefile | 2 +-
> 1 file
to 26MB.
>
> Signed-off-by: Arnd Bergmann
Agreed that COMPILE_TEST + GCOV_PROFILE_ALL is a very exotic combination
with little added use.
Acked-by: Peter Oberparleiter
> ---
> kernel/gcov/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/gcov/Kconfig
On 09.11.2015 05:23, Rusty Russell wrote:
> An exact mapping would be within_module_core(), but at this stage
> (MODULE_STATE_GOING) the init section is empty, and this is clearer.
>
> Cc: Peter Oberparleiter
> Signed-off-by: Rusty Russell
> ---
> kernel/gcov/base.c
Writing a number to /sys/bus/scsi/devices//queue_ramp_up_period
returns the value of that number instead of the number of bytes written.
This behavior can confuse programs expecting POSIX write() semantics.
Fix this by returning the number of bytes written instead.
Signed-off-by: Peter
Writing a number to /sys/bus/scsi/devices//queue_ramp_up_period
returns the value of that number instead of the number of bytes written.
This behavior can confuse programs expecting POSIX write() semantics.
Fix this by returning the number of bytes written instead.
Signed-off-by: Peter
h only one
element. This implicit bit of information would be lost when using
kzalloc. Therefore I'd like to keep the current version for better
readability.
> GFP_KERNEL);
> if (!node->loaded_info)
> goto
d for kernel profiling.
Looks sane and tests finished successfully on s390 with GCC 5.1.0 and
GCC 4.9.2.
Tested-by: Peter Oberparleiter
Reviewed-by: Peter Oberparleiter
> Signed-off-by: Lorenzo Stoakes
> ---
> kernel/gcov/base.c| 6 ++
> kernel/gcov/gcc_4_7.c | 4 +++-
Looks good. Andrew, can you pick this change up via your tree?
Acked-by: Peter Oberparleiter
On 09.10.2014 12:54, Riku Voipio wrote:
> Following up the arm testing of gcov, turns out gcov on ARM64
> works fine as well. Only change needed is adding ARM64 to Kconfig
> depends.
>
&
ov-io.h and libgcc/libgcov-merge.c
> For the first change, the layout of struct gcov_info is affected.
> For the second one, a dummy function is added to kernel/gcov/base.c similarly.
> Signed-off-by: Yuan Pengfei
Looks good. Tested successfully on s390x with both GCC 4.9 and GCC 4.3.4.
Ac
;
> static struct gcov_info *gcov_info_head;
> @@ -290,7 +295,7 @@ struct gcov_info *gcov_info_dup(struct gcov_info *info)
>
> dci_ptr->values = vmalloc(cv_size);
>
> - if (!dci_ptr->values)
> + if (cv_size && !dc
gcov/base.c:82:6: warning: no previous prototype for
> ‘__gcov_merge_ior’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
Acked-by: Peter Oberparleiter
> ---
> kernel/gcov/base.c |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/kernel/gcov/ba
blem of gcov_info.values == NULL
using the existing gcov-kernel infrastructure then I agree that this
should be fixed. If not, then I would rather see the suggested change as
part of a patch series that enables other profiling types.
--
Peter Oberparleiter
Linux on System z Development - IBM Ger
fei
I'm unaware of any user of -fprofile-values in the kernel. Are you
trying to extend gcov-kernel to also support -fprofile-values? I would
expect that additional changes to the .gcda file creation logic are
required to fully support this GCC option.
Regards,
Peter Oberparleiter
--
overage data: lcov -z
2. Run LTP (or any other test case)
3. Capture coverage data: lcov -c -o coverage.info
4. Generate HTML output: genhtml coverage.info -o out
5. View HTML output: out/index.html
More information on lcov can be found on the page behind the second URL
your quoted in your mail
Commit-ID: 6583327c4dd55acbbf2a6f25e775b28b3abf9a42
Gitweb: http://git.kernel.org/tip/6583327c4dd55acbbf2a6f25e775b28b3abf9a42
Author: Peter Oberparleiter
AuthorDate: Thu, 6 Feb 2014 15:58:20 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 6 Feb 2014 07:15:20 -0800
x86, hweight: Fix
On 05.02.2014 18:36, H. Peter Anvin wrote:
> On 02/05/2014 09:00 AM, Peter Oberparleiter wrote:
>>
>> Could you give this patch a try? It is a variation of the approach
>> proposed in the discussion mentioned earlier and fixes the problem
>> on my system.
>>
&g
On 31.01.2014 16:50, Peter Oberparleiter wrote:
> On 29.01.2014 21:44, Meelis Roos wrote:
>>>> I do not get very far - it still crashes on startuo. PNG attached.
>>>
>>> I tried to reproduce this behavior a couple of times with no success.
>>> Could you
line asm constraint being a potential
alternative. I've added Borislav Petkov and H. Peter Anvin who have been
involved in the discussion of this commit to CC:, hoping that they might
be able to provide a solution to this problem.
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60008
[2] http:/
On 28.01.2014 07:33, Meelis Roos wrote:
>> It looks like gcov exploded when running a module's constructors or
>> init function, but I'm unable to work out which module it was :(
> [...]
>
>> Maybe it's tg3.
>>
>> Could you add `ignore_loglevel' to the kernel boot parame
On 24.01.2014 21:54, Meelis Roos wrote:
It looks like gcov exploded when running a module's constructors or
init function, but I'm unable to work out which module it was :(
>>> [...]
>>>
Maybe it's tg3.
Could you add `ignore_loglevel' to the kernel boot parameters? That
>>
On 22.01.2014 16:33, Meelis Roos wrote:
>> It looks like gcov exploded when running a module's constructors or
>> init function, but I'm unable to work out which module it was :(
> [...]
>
>> Maybe it's tg3.
>>
>> Could you add `ignore_loglevel' to the kernel boot parameters? That
>> should make
Signed-off-by: Peter Oberparleiter
---
MAINTAINERS |6 ++
1 file changed, 6 insertions(+)
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3605,6 +3605,12 @@
S: Odd Fixes (e.g., new signatures)
F: drivers/scsi/fdomain.*
+GCOV BASED KERNEL PROFILING
+M: Peter Oberparleiter
+S
On 19.09.2013 12:21, Frantisek Hrbata wrote:
> On Thu, Sep 19, 2013 at 11:04:16AM +0200, Peter Oberparleiter wrote:
>> On 04.09.2013 16:42, Frantisek Hrbata wrote:
>>> The gcov in-memory format changed in gcc 4.7. The biggest change, which
>>> requires this spec
for mapping of function's counters to these arrays(offset). Now each
> gcov_fn_info contans it's counters, which makes things a little bit easier.
>
> This is heavily based on the previous gcc_3_4.c implementation and patches
> provided by Peter Oberparleiter. Specially
On 27.08.2013 15:34, Frantisek Hrbata wrote:
> On Mon, Aug 26, 2013 at 04:14:07PM +0200, Peter Oberparleiter wrote:
>> On 24.08.2013 21:44, Frantisek Hrbata wrote:
>>> On Fri, Aug 23, 2013 at 05:21:12PM +0200, Peter Oberparleiter wrote:
>>>> On 23.08.2013 17:15, Peter
or missing? Or anyone know how to enable GCOV on
> target board? Please advice.
> I would like to enable GCOV in arch/ code as well.
> Thank you very much.
--
Peter Oberparleiter
Linux on System z Development - IBM Germany
--
To unsubscribe from this list: send the line "unsubscrib
On 24.08.2013 21:44, Frantisek Hrbata wrote:
> On Fri, Aug 23, 2013 at 05:21:12PM +0200, Peter Oberparleiter wrote:
>> On 23.08.2013 17:15, Peter Oberparleiter wrote:
>>> On 23.08.2013 10:39, Frantisek Hrbata wrote:
>>>> Compile the correct gcov implementation file
On 24.08.2013 21:12, Frantisek Hrbata wrote:
> On Fri, Aug 23, 2013 at 05:15:19PM +0200, Peter Oberparleiter wrote:
>> Also it is my understanding that there are some distribution-specific
>> versions
>> of GCC that include the 4.7. gcov format code but report GCC version
On 23.08.2013 23:00, Frantisek Hrbata wrote:
> On Fri, Aug 23, 2013 at 05:12:19PM +0200, Peter Oberparleiter wrote:
>> On 23.08.2013 10:39, Frantisek Hrbata wrote:
>>> The gcov in-memory format changed in gcc 4.7. The biggest change, which
>>> requires this spec
On 23.08.2013 18:50, Frantisek Hrbata wrote:
> On Fri, Aug 23, 2013 at 05:09:58PM +0200, Peter Oberparleiter wrote:
>> On 23.08.2013 10:39, Frantisek Hrbata wrote:
>>> Since also the gcov structures(gcov_info, gcov_fn_info, gcov_ctr_info) can
>>> change between gcc re
On 23.08.2013 18:15, Frantisek Hrbata wrote:
> On Fri, Aug 23, 2013 at 05:08:07PM +0200, Peter Oberparleiter wrote:
>> Most of your code looks very familiar. There's one feature missing though
>> that Christophe brought up as a requirement: the ability for gcov-kernel
&g
On 23.08.2013 17:15, Peter Oberparleiter wrote:
> On 23.08.2013 10:39, Frantisek Hrbata wrote:
>> Compile the correct gcov implementation file for a specific gcc version. In
>> the future, if another file is added, the conditions will need to be somehow
>> adjusted to if-e
ONFIG_TRACEPOINTS
> @@ -3024,6 +3027,9 @@ static void do_mod_ctors(struct module *mod)
>
> for (i = 0; i < mod->num_ctors; i++)
> mod->ctors[i]();
> +
> + for (i = 0; i < mod->num_init_array; i++)
> + mod->init_array[i]();
> #endif
>
format configurable
Make the format of the generated gcov data configurable. This may be
required for example for pre-4.7 GCCs that contain the 4.7 gcov data
format changes.
Signed-off-by: Peter Oberparleiter
---
kernel/gcov/Kconfig | 30 ++
kernel/gcov/Makefile |
ormat-specific information needs
+ * to be kept modular and easily exchangeable.
+ *
+ * This file is based on gcc-internal definitions. Functions and data
+ * structures are defined to be compatible with gcc counterparts.
+ * For a better understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *Cop
V_COUNTERS5
The value for GCOV_COUNTERS has been changed with GCC 4.3. Before it was 5,
starting with GCC 4.3 the value is 8. While this is not strictly necessary, I'm
wondering if this should be added here to prevent any unwanted side-effects.
--
Peter Oberparleiter
Linux o
.
Back to your patches: I tested them and they work fine on s390x when
compiled with GCC 4.3.4 and 4.7.2. I'll provide some more specific
comments as replies to your patch-mails.
Regards,
Peter Oberparleiter
--
Peter Oberparleiter
Linux on System z Development - IBM Germany
--
To uns
On 14.09.2012 08:52, Dan Carpenter wrote:
We should free "node->loaded_info" on this error path. We'd never care
in real life but it makes the static checkers happy.
Signed-off-by: Dan Carpenter
---
v2: some style changes.
Signed-off-by: Peter Oberparleiter
or requires freeing. With the removal of the pr_warning
below, the additional kfree can also be added to err_nomem (no need for
another label) though then it should probably also be renamed.
err_nomem:
kfree(node);
- pr_warning("out of memory\n");
return NULL;
m code). Part of that work
has already been done by [EMAIL PROTECTED] and myself but we've stalled about
half-way due to a lack of time.
Seeing that there seems to be some support for the idea, I'll try to come up
with a patch for further discussion.
Regards,
Peter Oberparleiter
-
To
From: Peter Oberparleiter <[EMAIL PROTECTED]>
debugfs: implement symbolic links
Implement a new function debugfs_create_symlink() which can be used
to create symbolic links in debugfs. This function can be useful
for people moving functionality from /proc to debugfs (e.g. the
gcov-kernel
92 matches
Mail list logo
