I assume that the compiler based instrumentation,
should be more efficient than binary instrumentation.
But, I was just interested in the process of implementation
for that tool.
Sorry for the noise.
On 10/07/2018 11:03 AM, Richard Biener wrote:
> On October 6, 2018 10:17:48 PM GMT+02:00, De
Richard,
thanks for the answer, got it.
On 09/05/2018 07:51 PM, Richard Earnshaw (lists) wrote:
On 05/09/18 17:43, Denis Khalikov wrote:
Thanks for the answers.
I understood that, this hack makes more mess in codegen for arm,
but can you please clarify what did you mean by
Only a single
Thanks for the answers.
I understood that, this hack makes more mess in codegen for arm,
but can you please clarify what did you mean by
>Only a single register can be used
> as the frame chain.
As far as I understood, GCC for arm with THUMB2 mode uses r7 register as
frame pointer register by
Hi Wilco,
thanks for the answer.
> Adding support for a frame chain would require an ABI change. It
would have to
> work across GCC, LLVM, Arm, Thumb-1 and Thumb-2 - not a trivial amount of
> effort.
Clang already works that way.
Please look at this commit:
Hi Wilco,
thanks for the answer.
> Adding support for a frame chain would require an ABI change. It
would have to
> work across GCC, LLVM, Arm, Thumb-1 and Thumb-2 - not a trivial amount of
> effort.
Clang already works that way.
Please look at this commit:
Hello everyone,
can someone, please, take a look on this patch
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01656.html
Thanks.
Hi,
thanks for the answer.
> Switching on the frame pointer typically costs 1-2% performance, so
it's a bad
> idea to use it. However changing the frame pointer like in the
proposed patch
> will have a much larger cost - both in performance and codesize.
You'd be
> lucky if it is less than
ame layout like this.
It would be nice to get review for this patch by some experts. I could
miss a lot of corner cases.
Thanks.
From: Denis Khalikov
Date: Thu, 23 Aug 2018 16:33:58 +0300
Subject: [PATCH] Frame pointer for arm with THUMB2 mode.
Set frame pointer to the predictable l
Hello,
this is a patch for PR other/86198
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86198
Thanks.
From: Denis Khalikov
Date: Mon, 18 Jun 2018 20:46:39 +0300
Subject: [PATCH] PR other/86198
* elf.c (elf_add): Increase ".note.gnu.build-id" section size
checking up to 36 bytes.
---
li
Hello,
this is a patch for PR sanitizer/86090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86090
Thanks.
From: Denis Khalikov
Date: Fri, 8 Jun 2018 19:53:01 +0300
Subject: [PATCH] PR sanitizer/86090
* configure.ac: Check for lstat and readlink.
* configure, config.h.in: Rebuild
tch works for me.
Thanks.
On 09/11/2017 12:11 AM, Ian Lance Taylor wrote:
On Sat, Jul 29, 2017 at 1:42 PM, Denis Khalikov
<d.khali...@partner.samsung.com> wrote:
Hello Ian,
thanks for review.
I've updated the patch, can you please take a look.
Apologies again for the length of time i
Hello,
this is a ping for that patch:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01958.html
Thanks.
Hello,
this is a ping for that patch:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01958.html
Thanks.
Hello,
this is a ping for that patch
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00022.html
Thanks.
On 06/29/2017 02:59 AM, Ian Lance Taylor wrote:
On Fri, Jun 16, 2017 at 8:39 AM, Denis Khalikov
<d.khali...@partner.samsung.com> wrote:
Hello everyone,
This is a patch for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77631
Can some one please review attached patch.
Sorry to take s
Hello,
this is a ping for that patch
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00022.html
Thanks.
Hello,
this is a ping for that patch
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00022.html
Thanks.
Hello Ian,
thanks for review, I've fixed issues and updated the patch.
Can you please take a look.
Thanks.
On 06/29/2017 02:59 AM, Ian Lance Taylor wrote:
On Fri, Jun 16, 2017 at 8:39 AM, Denis Khalikov
<d.khali...@partner.samsung.com> wrote:
Hello everyone,
This is a patch for
Hello everyone,
this is a ping for patch
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01209.html
at path
/usr/lib/debug/.build-id/01/23456789abcdef0123456789abcdef01234567.debug
May be I'am missing something ?
I also can provide 3 more tests for this patch, but it will
increase patch size in about 1,5 times.
Thanks.
On 06/18/2017 05:08 PM, Matthias Klose wrote:
On 16.06.2017 17:39, Denis
Hello everyone,
This is a patch for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77631
Can some one please review attached patch.
Thanks.
From ae74cf3d632b06a91a986e32e3a6c16223767b24 Mon Sep 17 00:00:00 2001
From: Denis Khalikov <d.khali...@partner.samsung.com>
Date: Fri, 16 Jun 2017 12
Hello everyone,
this is a ping for that patch
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01462.html
Can someone please review that patch.
Thanks.
Hello everyone,
i've updated the patch recently for this issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77631
Can someone please review it.
Thanks.
On 04/13/2017 01:07 AM, Jeff Law wrote:
Given this doesn't look like a regression, I'm going to punt to gcc-8.
jeff
From: Denis Khalikov
Thanks for review.
I updated the patch.
On 04/13/2017 04:10 PM, Jakub Jelinek wrote:
On Thu, Apr 13, 2017 at 12:28:40PM +0300, Denis Khalikov wrote:
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/ubsan/bounds-15.c
@@ -0,0 +1,11 @@
+/* { dg-do run } */
+/* { dg-options "-fsanitize=b
Hello everyone.
I have patch to fix segfault with -fsanitize=undefined on 32 bit host.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80414
Can someone please review it.
Thanks.
commit 3bb53510ae11a9fa1f79ae83469c2650abe81ab4
Author: Denis Khalikov <d.khali...@partner.samsung.com>
Hello everyone,
this is a ping for
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01171.html
Hello everyone,
can someone please review that patch
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01171.html
Thanks.
strip, before test suite will run.
But the solution to move all test suite code from Makefile.in to
Makefile.am seems not really good.
I searched for default target, which can be run before test suite logic,
but can't find it for Makefile.am.
Should I keep current solution, or we have be
Thanks for answer, i got it now.
I will also delete all readlink code. Looks like is no reason
to use it instead just one call of realpath(char*,char*). Binutils
using realpath in the same cases.
On 03/14/2017 07:26 PM, Ian Lance Taylor wrote:
On Tue, Mar 14, 2017 at 7:30 AM, Denis Khalikov
_debuglink section?
Should i move code below
/* check if debug section does exist */
debug_link_data
= elf_gnu_debuglink_section (state, descriptor, error_callbackdata,
exe, _link_data_len);
from backtrace_open_debugfile .
On 03/14/2017 04:49 PM, Ian Lance Taylor wrote:
On Mon, Mar 13, 2017 at
Ok, thanks,
i will change patch to use crc32 from libiberty and
also implement searching for debuginfo with build id.
As it was implemented to binutils PR binutils/20876.
On 03/14/2017 04:21 PM, Ian Lance Taylor wrote:
On Tue, Mar 14, 2017 at 3:20 AM, Denis Khalikov
<d.kh
3, 2017 at 6:16 PM, Denis Khalikov
<d.khali...@partner.samsung.com> wrote:
Hello everyone, i have a patch for this issue.
Great!
List of implemented functionality:
1.Reading .gnu_debuglink section from ELF file:
a. Reading name of debug info file.
b. Verifying crc32 sum.
2. Searching
/to/executable
c. /path/to/executable/.debug
Assumed that debug info file generated by objcopy from binutils.
objcopy --only-keep-debug foo foo.debug
strip -g foo
objcopy --add-gnu-debuglink=foo.debug foo
commit 6147ee1a9aeeb748563a8998033f2ce195460162
Author: Denis Khalikov <d.kh
33 matches
Mail list logo