On Tue, Sep 30, 2014 at 07:27:51AM -0700, Dave Hansen wrote:
> On 09/30/2014 05:41 AM, Frantisek Hrbata wrote:
> > Does it make sense to replace "count" with "size" so it's consistent with
> > the
> > rest or do you prefer "nr_bytes" or a
There is no need to block read/write access to /dev/mem for phys. addr. above
high_memory for non-system RAM. The only limitation should be
boot_cpu_data.x86_phys_bits(max phys. addr. size).
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/mmap.c | 2 +-
1 file changed, 1 insertion(+), 1
quot;);
return 0;
}
-8<--
V3: use len_bytes instead of count, thanks to Dave Hansen and Thomas Gleixner
V2: fix pfn check in valid_mmap_phys_addr_range, thanks to Dave Hansen
Signed-off-by: Frantisek Hrbata
---
arch/x86
safely for
kernel mapped memory and it will also allow read/write to access non-system RAM
above high_memory once the high_memory check is removed from
valid_phys_addr_range.
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/ioremap.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions
valid reason to use high_memory check in (read|write)_mem.
The second patch removes the high_memory check from valid_phys_addr_range,
allowing read/write to access non-system RAM above high_memory. So far this
was possible only by using mmap.
I hope I haven't overlooked something.
Many thanks
Fran
Add helper to check maximum possible pfn on x86. Also make the current
phys_addr_valid helper using it internally.
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/physaddr.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/physaddr.h b/arch/x86/mm
On Mon, Sep 29, 2014 at 10:15:28PM +0200, Thomas Gleixner wrote:
> On Mon, 29 Sep 2014, Frantisek Hrbata wrote:
> > V2: fix pfn check in valid_mmap_phys_addr_range, thanks to Dave Hansen
>
> AFAICT, Dave also asked you to change size_t count into something more
> intuit
On Mon, Sep 29, 2014 at 10:15:28PM +0200, Thomas Gleixner wrote:
On Mon, 29 Sep 2014, Frantisek Hrbata wrote:
V2: fix pfn check in valid_mmap_phys_addr_range, thanks to Dave Hansen
AFAICT, Dave also asked you to change size_t count into something more
intuitive, i.e. nr_bytes or such.
Hi
Add helper to check maximum possible pfn on x86. Also make the current
phys_addr_valid helper using it internally.
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
arch/x86/mm/physaddr.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/physaddr.h b
.
The second patch removes the high_memory check from valid_phys_addr_range,
allowing read/write to access non-system RAM above high_memory. So far this
was possible only by using mmap.
I hope I haven't overlooked something.
Many thanks
Frantisek Hrbata (4):
x86: add arch_pfn_possible helper
x86
safely for
kernel mapped memory and it will also allow read/write to access non-system RAM
above high_memory once the high_memory check is removed from
valid_phys_addr_range.
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
arch/x86/mm/ioremap.c | 9 ++---
1 file changed, 6 insertions
There is no need to block read/write access to /dev/mem for phys. addr. above
high_memory for non-system RAM. The only limitation should be
boot_cpu_data.x86_phys_bits(max phys. addr. size).
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
arch/x86/mm/mmap.c | 2 +-
1 file changed, 1
;
}
-8--
V3: use len_bytes instead of count, thanks to Dave Hansen and Thomas Gleixner
V2: fix pfn check in valid_mmap_phys_addr_range, thanks to Dave Hansen
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
arch/x86/include/asm/io.h | 4
arch/x86
On Tue, Sep 30, 2014 at 07:27:51AM -0700, Dave Hansen wrote:
On 09/30/2014 05:41 AM, Frantisek Hrbata wrote:
Does it make sense to replace count with size so it's consistent with
the
rest or do you prefer nr_bytes or as Dave proposed len_bytes?
I don't care what it is as long as it has
Add helper to check maximum possible pfn on x86. Also make the current
phys_addr_valid helper using it internally.
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/physaddr.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/physaddr.h b/arch/x86/mm
ot;);
return 0;
}
-----8<--
V2: fix pfn check in valid_mmap_phys_addr_range, thanks to Dave Hansen
Signed-off-by: Frantisek Hrbata
---
arch/x86/include/asm/io.h | 4
arch/x86/mm/mmap.c| 12
2 f
safely for
kernel mapped memory and it will also allow read/write to access non-system RAM
above high_memory once the high_memory check is removed from
valid_phys_addr_range.
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/ioremap.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions
There is no need to block read/write access to /dev/mem for phys. addr. above
high_memory for non-system RAM. The only limitation should be
boot_cpu_data.x86_phys_bits(max phys. addr. size).
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/mmap.c | 2 +-
1 file changed, 1 insertion(+), 1
reason to use high_memory check in (read|write)_mem.
The second patch removes the high_memory check from valid_phys_addr_range,
allowing read/write to access non-system RAM above high_memory. So far this
was possible only by using mmap.
I hope I haven't overlooked something.
Many thanks
Franti
in (read|write)_mem.
The second patch removes the high_memory check from valid_phys_addr_range,
allowing read/write to access non-system RAM above high_memory. So far this
was possible only by using mmap.
I hope I haven't overlooked something.
Many thanks
Frantisek Hrbata (4):
x86: add
There is no need to block read/write access to /dev/mem for phys. addr. above
high_memory for non-system RAM. The only limitation should be
boot_cpu_data.x86_phys_bits(max phys. addr. size).
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
arch/x86/mm/mmap.c | 2 +-
1 file changed, 1
safely for
kernel mapped memory and it will also allow read/write to access non-system RAM
above high_memory once the high_memory check is removed from
valid_phys_addr_range.
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
arch/x86/mm/ioremap.c | 9 ++---
1 file changed, 6 insertions
;
}
-8--
V2: fix pfn check in valid_mmap_phys_addr_range, thanks to Dave Hansen
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
arch/x86/include/asm/io.h | 4
arch/x86/mm/mmap.c| 12
2 files changed, 16 insertions(+)
diff
Add helper to check maximum possible pfn on x86. Also make the current
phys_addr_valid helper using it internally.
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
arch/x86/mm/physaddr.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/physaddr.h b
safely for
kernel mapped memory and it will also allow read/write to access non-system RAM
above high_memory once the high_memory check is removed from
valid_phys_addr_range.
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/ioremap.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions
g read/write to access non-system RAM above high_memory. So far this was
possible only by using mmap.
I hope I haven't overlooked something.
Many thanks
Frantisek Hrbata (2):
x86: add high_memory check to (xlate|unxlate)_dev_mem_ptr
x86: remove high_memory check from valid_phys_addr_range
arch/x86/
There is no need to block read/write access to /dev/mem for phys. addr. above
high_memory for non-system RAM. The only limitation should be
boot_cpu_data.x86_phys_bits(max phys. addr. size).
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/mmap.c | 2 +-
1 file changed, 1 insertion(+), 1
There is no need to block read/write access to /dev/mem for phys. addr. above
high_memory for non-system RAM. The only limitation should be
boot_cpu_data.x86_phys_bits(max phys. addr. size).
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
arch/x86/mm/mmap.c | 2 +-
1 file changed, 1
safely for
kernel mapped memory and it will also allow read/write to access non-system RAM
above high_memory once the high_memory check is removed from
valid_phys_addr_range.
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
arch/x86/mm/ioremap.c | 9 ++---
1 file changed, 6 insertions
non-system RAM above high_memory. So far this was
possible only by using mmap.
I hope I haven't overlooked something.
Many thanks
Frantisek Hrbata (2):
x86: add high_memory check to (xlate|unxlate)_dev_mem_ptr
x86: remove high_memory check from valid_phys_addr_range
arch/x86/mm/ioremap.c | 9
On Fri, Aug 15, 2014 at 11:10:25AM -0700, Dave Hansen wrote:
> On 08/15/2014 04:44 AM, Frantisek Hrbata wrote:
> > +int valid_phys_addr_range(phys_addr_t addr, size_t count)
> > +{
> > + return addr + count <= __pa(high_memory);
> > +}
> > +
> > +int va
On Fri, Aug 15, 2014 at 11:10:25AM -0700, Dave Hansen wrote:
On 08/15/2014 04:44 AM, Frantisek Hrbata wrote:
+int valid_phys_addr_range(phys_addr_t addr, size_t count)
+{
+ return addr + count = __pa(high_memory);
+}
+
+int valid_mmap_phys_addr_range(unsigned long pfn, size_t count
ot;);
return 0;
}
-----8<--
V2: fix pfn check in valid_mmap_phys_addr_range, thanks to Dave Hansen
Signed-off-by: Frantisek Hrbata
---
arch/x86/include/asm/io.h | 4
arch/x86/mm/mmap.c| 12
2 f
kept from historic
reasons. I'm just curious and I of course may be missing something.
Many thanks
Frantisek Hrbata (2):
x86: add arch_pfn_possible helper
x86: add phys addr validity check for /dev/mem mmap
arch/x86/include/asm/io.h | 4
arch/x86/mm/mmap.c| 12
a
Add helper to check maximum possible pfn on x86. Also make the current
phys_addr_valid helper using it internally.
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/physaddr.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/physaddr.h b/arch/x86/mm
self-nack
As pointed by Dave Hansen, the check is just wrong. I will post V2.
Many thanks Dave!
--
Frantisek Hrbata
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.
self-nack
As pointed by Dave Hansen, the check is just wrong. I will post V2.
Many thanks Dave!
--
Frantisek Hrbata
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
historic
reasons. I'm just curious and I of course may be missing something.
Many thanks
Frantisek Hrbata (2):
x86: add arch_pfn_possible helper
x86: add phys addr validity check for /dev/mem mmap
arch/x86/include/asm/io.h | 4
arch/x86/mm/mmap.c| 12
arch/x86/mm
Add helper to check maximum possible pfn on x86. Also make the current
phys_addr_valid helper using it internally.
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
arch/x86/mm/physaddr.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/physaddr.h b
;
}
-8--
V2: fix pfn check in valid_mmap_phys_addr_range, thanks to Dave Hansen
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
arch/x86/include/asm/io.h | 4
arch/x86/mm/mmap.c| 12
2 files changed, 16 insertions(+)
diff
On Thu, Aug 14, 2014 at 10:20:53AM -0700, H. Peter Anvin wrote:
> On 08/14/2014 09:36 AM, Dave Hansen wrote:
> > Thanks for dredging this back up!
> >
> > On 08/14/2014 07:18 AM, Frantisek Hrbata wrote:
> >> +int valid_phys_addr_range(phys_addr_t addr, size_t coun
On Thu, Aug 14, 2014 at 09:36:03AM -0700, Dave Hansen wrote:
> Thanks for dredging this back up!
>
> On 08/14/2014 07:18 AM, Frantisek Hrbata wrote:
> > +int valid_phys_addr_range(phys_addr_t addr, size_t count)
> > +{
> > + return addr + count <= __pa(high_memory
ill get more attention or at least
to start the discussion how/if this should be fixed.
The patch is the same except I added a check for phys addr overflow before
calling phys_addr_valid. Maybe this check should be in do_mmap_pgoff.
Many thanks
Frantisek Hrbata (1):
x86: add phys addr validity check fo
YS_mmap2, NULL, ps, PROT_READ, MAP_SHARED, fd,
OFFSET);
if (map == MAP_FAILED)
die("cannot mmap");
c = map[0];
if (munmap(map, ps) == -1)
die("cannot munmap");
if (close(fd) == -1)
die("cannot close&
;
}
-8--
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
arch/x86/include/asm/io.h | 4
arch/x86/mm/mmap.c| 18 ++
2 files changed, 22 insertions(+)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index
to start the discussion how/if this should be fixed.
The patch is the same except I added a check for phys addr overflow before
calling phys_addr_valid. Maybe this check should be in do_mmap_pgoff.
Many thanks
Frantisek Hrbata (1):
x86: add phys addr validity check for /dev/mem mmap
arch/x86
On Thu, Aug 14, 2014 at 09:36:03AM -0700, Dave Hansen wrote:
Thanks for dredging this back up!
On 08/14/2014 07:18 AM, Frantisek Hrbata wrote:
+int valid_phys_addr_range(phys_addr_t addr, size_t count)
+{
+ return addr + count = __pa(high_memory);
+}
Is this correct on 32-bit
On Thu, Aug 14, 2014 at 10:20:53AM -0700, H. Peter Anvin wrote:
On 08/14/2014 09:36 AM, Dave Hansen wrote:
Thanks for dredging this back up!
On 08/14/2014 07:18 AM, Frantisek Hrbata wrote:
+int valid_phys_addr_range(phys_addr_t addr, size_t count)
+{
+ return addr + count = __pa
On Wed, Oct 02, 2013 at 11:36:09AM -0700, H. Peter Anvin wrote:
> On 10/02/2013 11:31 AM, Frantisek Hrbata wrote:
> > On Wed, Oct 02, 2013 at 10:46:35AM -0700, H. Peter Anvin wrote:
> >> On 10/02/2013 09:05 AM, Frantisek Hrbata wrote:
> >>> +
> >>> +
On Wed, Oct 02, 2013 at 10:46:35AM -0700, H. Peter Anvin wrote:
> On 10/02/2013 09:05 AM, Frantisek Hrbata wrote:
> > +
> > +int valid_phys_addr_range(phys_addr_t addr, size_t count)
> > +{
> > + return addr + count <= __pa(high_memory);
> > +}
> > +
&g
ct 2 11:24:02 amd-pence-01 kernel: RSP <7fff2d34da10>
Oct 2 11:24:02 amd-pence-01 kernel: ---[ end trace 8a123cd70049eebc ]---
---------8<--
Please note the PTE value 8008000a0225.
Signed-off-by: Frantisek Hrbata
---
arc
kernel: ---[ end trace 8a123cd70049eebc ]---
-8--
Please note the PTE value 8008000a0225.
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
arch/x86/include/asm/io.h | 4
arch/x86/mm/mmap.c| 13 +
2
On Wed, Oct 02, 2013 at 10:46:35AM -0700, H. Peter Anvin wrote:
On 10/02/2013 09:05 AM, Frantisek Hrbata wrote:
+
+int valid_phys_addr_range(phys_addr_t addr, size_t count)
+{
+ return addr + count = __pa(high_memory);
+}
+
+int valid_mmap_phys_addr_range(unsigned long pfn, size_t
On Wed, Oct 02, 2013 at 11:36:09AM -0700, H. Peter Anvin wrote:
On 10/02/2013 11:31 AM, Frantisek Hrbata wrote:
On Wed, Oct 02, 2013 at 10:46:35AM -0700, H. Peter Anvin wrote:
On 10/02/2013 09:05 AM, Frantisek Hrbata wrote:
+
+int valid_phys_addr_range(phys_addr_t addr, size_t count
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 special implementation, is that gcov_info no longer contains
> &
On Wed, Sep 18, 2013 at 02:31:27PM -0700, Andrew Morton wrote:
> On Wed, 18 Sep 2013 14:27:05 -0700 Joe Perches wrote:
>
> > On Wed, 2013-09-18 at 14:22 -0700, Andrew Morton wrote:
> > > On Wed, 4 Sep 2013 16:42:54 +0200 Frantisek Hrbata
> > > wrote:
> > &
On Wed, Sep 18, 2013 at 02:31:27PM -0700, Andrew Morton wrote:
On Wed, 18 Sep 2013 14:27:05 -0700 Joe Perches j...@perches.com wrote:
On Wed, 2013-09-18 at 14:22 -0700, Andrew Morton wrote:
On Wed, 4 Sep 2013 16:42:54 +0200 Frantisek Hrbata fhrb...@redhat.com
wrote:
The gcov
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 special implementation, is that gcov_info no longer contains
array of counters for each
On Tue, Sep 10, 2013 at 03:05:57PM +0930, Rusty Russell wrote:
> Frantisek Hrbata writes:
> > On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote:
> >> Kyle McMartin writes:
> >> > On Fri, Sep 06, 2013 at 07:51:18PM +0200, Frantisek Hrbata wrote:
>
On Tue, Sep 10, 2013 at 03:05:57PM +0930, Rusty Russell wrote:
Frantisek Hrbata fhrb...@redhat.com writes:
On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote:
Kyle McMartin k...@infradead.org writes:
On Fri, Sep 06, 2013 at 07:51:18PM +0200, Frantisek Hrbata wrote:
v2
On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote:
> Kyle McMartin writes:
> > On Fri, Sep 06, 2013 at 07:51:18PM +0200, Frantisek Hrbata wrote:
> >> > > v2: - reuse mod->ctors for .init_array section for modules, because
> >> > > gcc
On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote:
Kyle McMartin k...@infradead.org writes:
On Fri, Sep 06, 2013 at 07:51:18PM +0200, Frantisek Hrbata wrote:
v2: - reuse mod-ctors for .init_array section for modules, because
gcc uses
.ctors or .init_array
On Fri, Sep 06, 2013 at 11:43:08AM +0930, Rusty Russell wrote:
> Frantisek Hrbata writes:
> > This adds the .init_array section as yet another section with constructors.
> > This
> > is needed because gcc could add __gcov_init calls to .init_array or .ctors
> > sectio
On Fri, Sep 06, 2013 at 11:43:08AM +0930, Rusty Russell wrote:
Frantisek Hrbata fhrb...@redhat.com writes:
This adds the .init_array section as yet another section with constructors.
This
is needed because gcc could add __gcov_init calls to .init_array or .ctors
section, depending on gcc
provided by Peter Oberparleiter. Detailed
description in patches.
Frantisek Hrbata (4):
gcov: move gcov structs definitions to a gcc version specific file
gcov: add support for gcc 4.7 gcov format
gcov: compile specific gcov implementation based on gcc version
kernel: add support
code and to
introduce simple helpers for accessing data inside gcov_info.
Signed-off-by: Frantisek Hrbata
---
kernel/gcov/base.c| 26 ++--
kernel/gcov/fs.c | 27 ++--
kernel/gcov/gcc_3_4.c | 115 ++
kernel/gcov/gcov.h
in gcov_info
- use vmalloc for counter values in gcov_info_dup
- use iter buffer for gcda
Signed-off-by: Frantisek Hrbata
---
kernel/gcov/base.c| 6 +
kernel/gcov/gcc_4_7.c | 562 ++
2 files changed, 568 insertions(+)
create mode 100644
ray, but not both at the same time
Signed-off-by: Frantisek Hrbata
---
include/asm-generic/vmlinux.lds.h | 1 +
kernel/module.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index 69732d2..c55d8d9 100
-by: Frantisek Hrbata
---
Documentation/gcov.txt | 4
kernel/gcov/Kconfig| 30 ++
kernel/gcov/Makefile | 32 +++-
3 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/Documentation/gcov.txt b/Documentation/gcov.txt
index e7ca647
-by: Frantisek Hrbata fhrb...@redhat.com
---
Documentation/gcov.txt | 4
kernel/gcov/Kconfig| 30 ++
kernel/gcov/Makefile | 32 +++-
3 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/Documentation/gcov.txt b/Documentation/gcov.txt
in gcov_info
- use vmalloc for counter values in gcov_info_dup
- use iter buffer for gcda
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
kernel/gcov/base.c| 6 +
kernel/gcov/gcc_4_7.c | 562 ++
2 files changed, 568 insertions
, but not both at the same time
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
include/asm-generic/vmlinux.lds.h | 1 +
kernel/module.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index
code and to
introduce simple helpers for accessing data inside gcov_info.
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
kernel/gcov/base.c| 26 ++--
kernel/gcov/fs.c | 27 ++--
kernel/gcov/gcc_3_4.c | 115
provided by Peter Oberparleiter. Detailed
description in patches.
Frantisek Hrbata (4):
gcov: move gcov structs definitions to a gcc version specific file
gcov: add support for gcc 4.7 gcov format
gcov: compile specific gcov implementation based on gcc version
kernel: add support
On Wed, Aug 28, 2013 at 03:46:05PM +0200, Peter Oberparleiter wrote:
> 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, 2
On Wed, Aug 28, 2013 at 03:46:05PM +0200, Peter Oberparleiter wrote:
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
On Mon, Aug 26, 2013 at 02:45:10PM +0200, Peter Oberparleiter wrote:
> 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-me
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 Oberparleiter wrote:
> >>> On 23.08.2013
On Mon, Aug 26, 2013 at 02:56:04PM +0200, Peter Oberparleiter wrote:
> 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
> &g
On Mon, Aug 26, 2013 at 02:56:04PM +0200, Peter Oberparleiter wrote:
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
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 Oberparleiter wrote:
On 23.08.2013 10:39, Frantisek Hrbata wrote:
Compile
On Mon, Aug 26, 2013 at 02:45:10PM +0200, Peter Oberparleiter wrote:
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
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 for a specific gcc version. In
> >> the futur
On Fri, Aug 23, 2013 at 05:15:19PM +0200, 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 someh
On Fri, Aug 23, 2013 at 05:15:19PM +0200, 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-elif-else
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 for a specific gcc version. In
the future, if another file is added, the conditions
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 special implementation, is that gcov_info no longer contains
> &
On Fri, Aug 23, 2013 at 05:13:31PM +0200, Peter Oberparleiter wrote:
> On 23.08.2013 10:39, Frantisek Hrbata wrote:
> > This adds the .init_array section as yet another section with constructors.
> > This
> > is needed because gcc is adding __gcov_init calls to .init_array
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 releases, as shown in gcc 4.7, they cannot be defined in
&
On Fri, Aug 23, 2013 at 05:08:07PM +0200, Peter Oberparleiter wrote:
> On 23.08.2013 10:39, Frantisek Hrbata wrote:
> > This is an attempt to bring support for modified gcov format in gcc 4.7 to
> > the kernel. It tries to leverage the existing layout/abstraction, which was
>
This adds the .init_array section as yet another section with constructors. This
is needed because gcc is adding __gcov_init calls to .init_array.
Signed-off-by: Frantisek Hrbata
---
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/module.h| 2 ++
kernel/module.c
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-elif-else case, but at this point the simple cc-ifversion should
be enough.
Signed-off-by: Frantisek Hrbata
---
kernel/gcov
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.
Signed-off-by: Frantisek Hrbata
---
kernel/gcov/base.c| 6 +
kernel/gcov/gcc_4_7.c | 612 ++
2
code and to
introduce simple helpers for accessing data inside gcov_info.
Signed-off-by: Frantisek Hrbata
---
kernel/gcov/base.c| 26 ++--
kernel/gcov/fs.c | 27 ++--
kernel/gcov/gcc_3_4.c | 115 ++
kernel/gcov/gcov.h
into account that
even the core gcov structures, like gcov_info, could change. One part that could
be problematic is the addition of the .init_array section for constructors.
Tested with lcov and seems to be working fine, giving similar results as for the
older format.
Frantisek Hrbata (4):
gcov: move
into account that
even the core gcov structures, like gcov_info, could change. One part that could
be problematic is the addition of the .init_array section for constructors.
Tested with lcov and seems to be working fine, giving similar results as for the
older format.
Frantisek Hrbata (4):
gcov: move
code and to
introduce simple helpers for accessing data inside gcov_info.
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
kernel/gcov/base.c| 26 ++--
kernel/gcov/fs.c | 27 ++--
kernel/gcov/gcc_3_4.c | 115
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.
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
kernel/gcov/base.c| 6 +
kernel/gcov/gcc_4_7.c | 612
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-elif-else case, but at this point the simple cc-ifversion should
be enough.
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
This adds the .init_array section as yet another section with constructors. This
is needed because gcc is adding __gcov_init calls to .init_array.
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
---
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/module.h| 2 ++
kernel
1 - 100 of 122 matches
Mail list logo
