From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19596 invoked by alias); 19 Jun 2017 08:48:53 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 19551 invoked by uid 89); 19 Jun 2017 08:48:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,TRACKER_ID,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=HContent-transfer-encoding:8bit, 992, ID, HTo:D*ubuntu.com X-HELO: mailout4.w1.samsung.com Received: from mailout4.w1.samsung.com (HELO mailout4.w1.samsung.com) (210.118.77.14) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Jun 2017 08:48:47 +0000 MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0ORS004OLDTCEW30@mailout4.w1.samsung.com> for gcc-patches@gcc.gnu.org; Mon, 19 Jun 2017 09:48:48 +0100 (BST) Received: from eusmges3.samsung.com (unknown [203.254.199.242]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20170619084847eucas1p1457a03f2b5e673a390e300ea2ec5279c~JeatYxKhT1854918549eucas1p1X; Mon, 19 Jun 2017 08:48:47 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges3.samsung.com (EUCPMTA) with SMTP id 70.7F.17464.FEF87495; Mon, 19 Jun 2017 09:48:47 +0100 (BST) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20170619084847eucas1p19fe4e6afa38897d758bddd4ffdbaf5f4~Jeaspkfl82446024460eucas1p12; Mon, 19 Jun 2017 08:48:47 +0000 (GMT) Received: from eusync4.samsung.com ( [203.254.199.214]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id C7.E6.17452.FEF87495; Mon, 19 Jun 2017 09:48:47 +0100 (BST) Received: from [106.109.129.179] by eusync4.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0ORS005NMDTAW730@eusync4.samsung.com>; Mon, 19 Jun 2017 09:48:47 +0100 (BST) Subject: Re: [PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace To: Matthias Klose , GCC Patches From: Denis Khalikov Message-id: <61270d7f-435d-c20a-a7f2-cfe518b912e0@partner.samsung.com> Date: Mon, 19 Jun 2017 08:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 In-reply-to: Content-transfer-encoding: 8bit X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170619084847eucas1p19fe4e6afa38897d758bddd4ffdbaf5f4 X-Msg-Generator: CA X-Sender-IP: 182.198.249.179 X-Local-Sender: =?UTF-8?B?RGVuaXMgS2hhbGlrb3YbU1JSLVNXIFRvb2xzIExhYhvsgrw=?= =?UTF-8?B?7ISx7KCE7J6QG0VuZ2luZWVy?= X-Global-Sender: =?UTF-8?B?RGVuaXMgS2hhbGlrb3YbU1JSLVNXIFRvb2xzIExhYhtTYW1z?= =?UTF-8?B?dW5nIEVsZWN0cm9uaWNzG0VuZ2luZWVy?= X-Sender-Code: =?UTF-8?B?QzEwG0NJU0hRG0MxMEdEMDFHRDAxMDE1Nw==?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20170616153942eucas1p1945271f893265484bbb3991a368bcd92 X-RootMTR: 20170616153942eucas1p1945271f893265484bbb3991a368bcd92 References: <2b505c8c-a836-6079-f744-3e9f8acf9356@partner.samsung.com> X-SW-Source: 2017-06/txt/msg01273.txt.bz2 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 nn/nnnnnnnn.debug, where nn are the first 2 hex characters of the build ID bit string, and nnnnnnnn are the rest of the bit string. (Real build ID strings are 32 or more hex characters, not 10.)" I also check gdb internals, for PR binutils/20876, which you provided. 1926 build_id = get_build_id (abfd); 1927 if (build_id == NULL) 1928 return NULL; 1929 1930 /* Compute the debug pathname corresponding to the build-id. */ 1931 name = bfd_malloc (strlen (".build-id/") + build_id->size * 2 + 2 + strlen (".debug")); 1932 if (name == NULL) 1933 { 1934 bfd_set_error (bfd_error_no_memory); 1935 return NULL; 1936 } 1937 n = name; 1938 d = build_id->data; 1939 s = build_id->size; 1940 1941 n += sprintf (n, ".build-id/"); 1942 n += sprintf (n, "%02x", (unsigned) *d++); s--; 1943 n += sprintf (n, "/"); 1944 while (s--) 1945 n += sprintf (n, "%02x", (unsigned) *d++); 1946 n += sprintf (n, ".debug"); 1947 In my patch I do the same, in case we can't use printf functions family, because we can't use malloc. 972 debug_postfix = ".debug"; 973 debug_prefix = ".build-id/"; ... 990 memset (build_id_name, 0, *len); 991 memcpy (build_id_name, debug_prefix, debug_prefix_len); 992 temp = build_id_name + debug_prefix_len; 993 994 *temp++ = hex ((*hash_start & 0xF0) >> 4); 995 *temp++ = hex (*hash_start & 0x0F); 996 ++hash_start; 997 --hash_size; 998 999 memcpy (temp, "/", 1); 1000 ++temp; 1001 1002 while (hash_size--) 1003 { 1004 *temp++ = hex ((*hash_start & 0xF0) >> 4); 1005 *temp++ = hex (*hash_start & 0x0F); 1006 ++hash_start; 1007 } In this case if we have binary with build id: 0x0123456789abcdef0123456789abcdef01234567 For example we can use linker option to specify build-id manually: -Wl,--build-id=0x0123456789abcdef0123456789abcdef01234567 I expect to find .build-id link to debug file at least 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 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 releases you find these at > > $ ls /usr/lib/debug/.build-id/ > 00/ 0d/ 1a/ 25/ 2e/ 3a/ 45/ 4d/ 57/ 64/ 6d/ 77/ 82/ 8b/ 94/ a0/ a9/ b7/ c1/ cd/ > d6/ e0/ eb/ f6/ > 01/ 0e/ 1b/ 26/ 2f/ 3b/ 46/ 4e/ 58/ 65/ 6e/ 78/ 83/ 8c/ 95/ a1/ ac/ b9/ c4/ ce/ > d7/ e1/ ec/ f7/ > 02/ 11/ 1c/ 27/ 30/ 3d/ 47/ 50/ 59/ 66/ 6f/ 79/ 84/ 8e/ 96/ a2/ ae/ ba/ c5/ d0/ > d8/ e3/ ee/ f9/ > 03/ 15/ 1d/ 28/ 32/ 3e/ 48/ 51/ 5b/ 67/ 70/ 7a/ 85/ 8f/ 99/ a3/ b0/ bb/ c6/ d1/ > d9/ e4/ ef/ fb/ > 05/ 16/ 1e/ 29/ 35/ 41/ 49/ 52/ 5c/ 68/ 72/ 7b/ 87/ 90/ 9a/ a4/ b1/ bc/ c8/ d2/ > db/ e5/ f1/ fc/ > 08/ 17/ 1f/ 2a/ 36/ 42/ 4a/ 53/ 5e/ 69/ 73/ 7c/ 88/ 91/ 9b/ a5/ b2/ be/ c9/ d3/ > dc/ e6/ f2/ fd/ > 09/ 18/ 20/ 2b/ 37/ 43/ 4b/ 54/ 60/ 6a/ 75/ 7f/ 89/ 92/ 9c/ a6/ b4/ bf/ cb/ d4/ > dd/ e7/ f3/ fe/ > 0a/ 19/ 24/ 2d/ 39/ 44/ 4c/ 55/ 61/ 6b/ 76/ 80/ 8a/ 93/ 9f/ a7/ b5/ c0/ cc/ d5/ > de/ e8/ f5/ ff/ > > the first two bytes of the crc make the sub dir name, the debug file name has > these first two bytes omitted. > > $ ls /usr/lib/debug/.build-id/0d > c55467dc9eb81a00c7715a790844e7cf035345.debug > > objdump/objcopy in binutils 2.28 has these lookups properly working. > > Matthias > > >