On Mon, Oct 02, 2017 at 01:32:01PM +0200, Jakub Jelinek wrote:
> On Mon, Oct 02, 2017 at 01:12:24PM +0200, Martin Liška wrote:
> > Hi.
> >
> > Currently I see with --with-build-config=bootstrap-ubsan:
> >
> > /home/marxin/BIG/buildbot/slave/gcc-master-bootstrap-ubsan/build/builddir/prev-x86_64-pc
On Mon, Oct 02, 2017 at 01:12:24PM +0200, Martin Liška wrote:
> Hi.
>
> Currently I see with --with-build-config=bootstrap-ubsan:
>
> /home/marxin/BIG/buildbot/slave/gcc-master-bootstrap-ubsan/build/builddir/prev-x86_64-pc-linux-gnu/libsanitizer/ubsan/.libs/libubsan.a(elf.o):
> In function `back
Hi.
Currently I see with --with-build-config=bootstrap-ubsan:
/home/marxin/BIG/buildbot/slave/gcc-master-bootstrap-ubsan/build/builddir/prev-x86_64-pc-linux-gnu/libsanitizer/ubsan/.libs/libubsan.a(elf.o):
In function `backtrace_uncompress_zdebug':
/home/marxin/BIG/buildbot/slave/gcc-master-boots
On Sun, Sep 10, 2017 at 2:11 PM, Ian Lance Taylor wrote:
> On Sat, Jul 29, 2017 at 1:42 PM, Denis Khalikov
> wrote:
>>
>> Hello Ian,
>> thanks for review.
>> I've updated the patch, can you please take a look.
>
> Apologies again for the length of time it took to reply. I've had a
> hard time un
On Wed, Sep 20, 2017 at 1:53 AM, Maxim Ostapenko
wrote:
> Hi Ian,
>
> On 12/09/17 17:05, Ian Lance Taylor via gcc-patches wrote:
>>
>> On Mon, Sep 11, 2017 at 3:06 AM, Denis Khalikov
>> wrote:
>>>
>>> Thanks for answer.
>>> I understood all points which you mentioned, but can't
>>> find last one
Hi Ian,
On 12/09/17 17:05, Ian Lance Taylor via gcc-patches wrote:
On Mon, Sep 11, 2017 at 3:06 AM, Denis Khalikov
wrote:
Thanks for answer.
I understood all points which you mentioned, but can't
find last one
It seems to work
out the file name a second time, even though the file name must
al
On Mon, Sep 11, 2017 at 3:06 AM, Denis Khalikov
wrote:
> Thanks for answer.
> I understood all points which you mentioned, but can't
> find last one
>> It seems to work
>> out the file name a second time, even though the file name must
>> already be known.
>
> Can you please show me where I've mis
Thanks for answer.
I understood all points which you mentioned, but can't
find last one
> It seems to work
> out the file name a second time, even though the file name must
> already be known.
Can you please show me where I've missed that, if you have a time for that.
Anyway, your patch works fo
On Sat, Jul 29, 2017 at 1:42 PM, Denis Khalikov
wrote:
>
> Hello Ian,
> thanks for review.
> I've updated the patch, can you please take a look.
Apologies again for the length of time it took to reply. I've had a
hard time understanding the patch. It's quite likely that I don't
understand how 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.
Hello,
this a ping for that patch
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01958.html
Thanks.
On 06/29/2017 02:59 AM, Ian Lance Taylor wrote:
On Fri, Jun 16, 2017 at 8:39 AM, Denis Khalikov
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 so long about this. It's a lot to look at.
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
wrote:
Hello everyone,
This is a patch for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7
On Fri, Jun 16, 2017 at 8:39 AM, Denis Khalikov
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 so long about this. It's a lot to look at.
> diff --git a/libbacktrace/ChangeLog b/l
Hello everyone,
this is a ping for patch
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01209.html
Hello Matthias,
thanks for review.
As far as I understood that build-id should look like this:
https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
"For the “build ID” method, GDB looks in the .build-id subdirectory of
each one of the global debug directories for a file named
n
On 16.06.2017 17:39, Denis Khalikov 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.
not a full review, but it looks like the system debug files based on build-id's
are not found. In newer distro r
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
Date: Fri, 16 Jun 2017 12:13:13 +0300
Subject: [PATCH] PR saniti
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
D
On 03/22/2017 09:28 AM, Denis Khalikov wrote:
Hello everyone,
I've fixed some issues and implemented functionality
to search debug file by build-id.
Can someone please review my patch.
Given this doesn't look like a regression, I'm going to punt to gcc-8.
jeff
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.
Hello everyone,
I've fixed some issues and implemented functionality
to search debug file by build-id.
Can someone please review my patch.
> As far as I know all the debuglink code is ELF-specific. I would do
> it all in elf.c. While reading the sections of the executable, look
> for a debuglin
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
wro
On Tue, Mar 14, 2017 at 7:30 AM, Denis Khalikov
wrote:
> Thanks for review, got all of my mistakes, except one.
>
>
>> - descriptor = backtrace_open (info->dlpi_name, pd->error_callback,
>> - pd->data, &does_not_exist);
>> + descriptor
>> + = backtrace_open_debugfile (info->dlpi_name,
Thanks for review, got all of my mistakes, except one.
> - descriptor = backtrace_open (info->dlpi_name, pd->error_callback,
> - pd->data, &does_not_exist);
> + descriptor
> + = backtrace_open_debugfile (info->dlpi_name, pd->error_callback,
pd->data,
> +&debugfile_does_not_exis
On Mon, Mar 13, 2017 at 10:16 AM, Denis Khalikov
wrote:
> Hello everyone, i have a patch for this issue.
>
> 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 for separate debug
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
wrote:
Thanks for review,
On Tue, Mar 14, 2017 at 3:20 AM, Denis Khalikov
wrote:
> Thanks for review,
>
>> Skimming over the patch I noticed you duplicate libiberties xcrc32
>> functionality.
>
> should i take care about standalone libbacktrace ?
> https://github.com/ianlancetaylor/libbacktrace
No, don't worry about it.
Thanks for review,
> Skimming over the patch I noticed you duplicate libiberties xcrc32
> functionality.
should i take care about standalone libbacktrace ?
https://github.com/ianlancetaylor/libbacktrace
> Also the additions to posix.c probably belong to dwarf.c and elf.c
(the feature
> is dwa
On 14.03.2017 09:27, Richard Biener wrote:
> On Mon, Mar 13, 2017 at 6:16 PM, Denis Khalikov
> 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.
On Mon, Mar 13, 2017 at 6:16 PM, Denis Khalikov
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 for separate
Hello everyone, i have a patch for this issue.
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 for separate debug info file from paths:
a. /usr/lib/debug/path/to/executable
b. /path/t
38 matches
Mail list logo
