From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757278AbcHWMsw (ORCPT ); Tue, 23 Aug 2016 08:48:52 -0400 Received: from mail-db5eur01on0106.outbound.protection.outlook.com ([104.47.2.106]:52672 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752554AbcHWMst (ORCPT ); Tue, 23 Aug 2016 08:48:49 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=matija.glavinic-pecotic.ext@nokia.com; Subject: Re: [PATCH RFC RESEND] Perf: lookup dwarf unwind stack info in debug file pointed by .gnu_debuglink To: Jiri Olsa References: <2d72fb64-9b9c-7aa1-5ac5-ac710ec5a900@nokia.com> <20160822151919.GA614@krava> <20160823112204.GC6486@krava> CC: , , Namhyung Kim , Masami Hiramatsu From: Matija Glavinic Pecotic Message-ID: <69a799bb-1c54-928e-f58b-fdc8bb3fac0c@nokia.com> Date: Tue, 23 Aug 2016 14:33:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160823112204.GC6486@krava> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [131.228.2.8] X-ClientProxiedBy: AM5PR0501CA0037.eurprd05.prod.outlook.com (10.164.187.47) To DB6PR0701MB2166.eurprd07.prod.outlook.com (10.168.58.21) X-MS-Office365-Filtering-Correlation-Id: ee7f9083-21d6-4f29-0154-08d3cb51be9e X-Microsoft-Exchange-Diagnostics: 1;DB6PR0701MB2166;2:VRRGF3BugC7QwwJ7/tsjvY9ttiD6IwVLPtK4499R2jkqFxbMe2hy7j9Y4zEd7yZQ6wjyA0sxfCeLHf7L1zGYeHqwtAIeM0CldokLKlnS89aHwTpBPKYvPM9zVKMfR66pcDvlEWa4ywbOXtr013lhmj6A+UKvabX9wSBLS3KmWjOqfsIwZJTuiMd7OEQJhg6i;3:M/SDSbijjRLY1/d3q9Nek91ibGXRVzVrykan0BfLZENqsqQMgtk8Yy7SMHa8VMVCgV7w+dj+xjthqkQI1r9l9in2iFQOxaTgkw0zpHkUePaMgcRbqUc3xVyDW2mS9oL7 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0701MB2166; X-Microsoft-Exchange-Diagnostics: 1;DB6PR0701MB2166;25:ECkaVTpuHvsE9PA5YLm3mLMBlbJGU3uh/7IG1z3SEScxnP1o9KzD9TjS5jmPKVfDkfj2ySGKW54kOj/DSfCVQlybgiRopRlISSopOgW3iH7aXv+7o0dEjv4meMBw4GBVHgE4lkQAjqFG8UBpZ2iDVKVP1zCFgog+PA3YmsUQmg7zvsBMrtf3dwFSlVP8xwHqgXraENnmcgX6Rz9ACvBf0D3iJbHrA+5h268x4N8OJbgI07J1llelqdFmiy2nyGhseOeKj2Lp3VfbRMjulrTMllzg1yURQtZ8X5d9MPWiiQ+/bftz5JVUytTobVX52CuuAV9ky4xmszbZs+s7SPiw1HxD/ZJxQyhTmSEH0iIVAoigtrxDfMIey6ppOe/mnViCHqSCYw5c0tO+OZKnhTu199d9ycop23YzEavAaXutf71QCvdjReX0aeN8sdCWXogQhhB2p67A9D6oRJIWm2HsicGKXsa/WogXFkK0PEmWAprcrGu0dKMjoGY0bi4Eg/tJsy4cy/tEghU7PrN48ZxDSAw2WoVaZtYkuBG65oXDKfA5L61O4DVJLENDCgqXQwl8NshHYyPBhQWwbPBq1AqMjrcQkSHrEyvhLs2qMipUGQZ3So628EIYKFsXfnAqDL7UhMUINKcgcEAHjLy/9MiaXHY/KUAV3C7SAvWmLq9l2SxrNUvhPlMUIUFXAQWxfsE8IqKwUqMT1RVW8VenCfmaAteuC7zxxR91WjkmeFo83eDmMhKueNk7fZivVZ87L1tmCVEZm62ZHbuId3unpjUffz/G3FX7/4PjJyUmHwVVN51B2OAt2yO2Aj1f1p7T7tmlENCVh4B1kAhy22fVdWUQpA== X-Microsoft-Exchange-Diagnostics: 1;DB6PR0701MB2166;31:z/SmZz66IZeymnd0K0Wz5Rvkrwhm9KSP/6fI5jlRzaWq1jt51MDrMq913BKec2CjNcVbkUlhUB1dwx3c7oXHK3l2g0zVuFFojC+x8giUfoqqcLWF358FKCLOElDv1Yl9o8z+aFOLf6R+0EKAYBLuL/6n0yttMe22SwcBVwaO8VW0Ew0RsOHzzpNPRwkOw64TRoa0u+MvUBjX9CHyedaXY37X9bXzDJC5iqCCRW4My6Y=;20:RrA4KyTSLUdzj8SVkrPHsIUULBBq3EVtc8OFl+wQOsixzhCsBGpzRvZFTQ8za2rAgyXz92R5qEmQyn0aihIw+9Kc6j5V0V98ikT2uZUgvDamY3UtpkxFkrRb1QnWL4k+7aypoqLu9cBnYRcG5TV4T7xB9LJUCNJAC9+T7Ar47QhyDyjZQEfdxvkO6/8iBUv8S/iUKu9A94bi8ySZpyf0CkncrTl9bTdeEQG6sF4idJCD4S+ADo5IlFRyyZ3eqRHKBpTfCHsXl7W28PVg5mRCKHmvTOh3eG6BdFUSgkzufoilmZlkmi+REGpmQhONNvpn26xA3YDSb/TcGcRZVlunevJnc2lQq2Ie0cqR8LwfUUQkTi1PUqjWoP9rTI3YIOKqygwmtuu0WSILfor7M9mmBKWJcTOS8BEMtDDgERHecCLNmK7gG6B3c7Mbte9uIqWACf3GBTXUJIzs0UpAQQLjH3cYduNzn/XPWwow3Iy330vJTKT4V18jPYiGWv1eIm75 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026);SRVR:DB6PR0701MB2166;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0701MB2166; X-Microsoft-Exchange-Diagnostics: 1;DB6PR0701MB2166;4:TzEKyv5eGHwHZdsfzbwhkOSZzmouHaY3cJZAy+H7ANc5w4SQuts1kRYtwnJVa7DrQV6DSgUAIdwIKDVMgmKHKDsh6yw3iNNjldowKvp9BjFPLa2VoCINBHm2V6hjcwQe/XmEFqM7cb58o3VcHr9zkxiH9HjE3cr16xi5zRFE10VviW/UavJkq2qcTkvIKAogtOzFhch6T8JMQMj9b6ywyXzGHGDSolLaxDMCx3RrvIH5zjhLOZENw4DMRwpKgbTs/zhHAcgXilxXzIR5Y/78vmiv5TmPv88Foey9zTDq4VLIxhwiXwWv/IH7ImdvDW2cPWDqCvVxTx9GrVuaiZMWe0KW61uN2MA2h8mgbxc/kbdmHo6S+PO7ktnDDKHuGN4COM4TQlQbgwy6iyT51S79XA== X-Forefront-PRVS: 004395A01C X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(199003)(52054003)(189002)(24454002)(33646002)(2906002)(105586002)(4326007)(189998001)(4001350100001)(86362001)(575784001)(93886004)(83506001)(6116002)(110136002)(3846002)(31686004)(42186005)(76176999)(97736004)(50986999)(106356001)(230700001)(101416001)(586003)(66066001)(36756003)(31696002)(19580395003)(64126003)(68736007)(81156014)(305945005)(7736002)(47776003)(54356999)(7846002)(23746002)(5660300001)(50466002)(8676002)(81166006)(92566002)(77096005)(15975445007)(2950100001)(142923001)(217873001);DIR:OUT;SFP:1102;SCL:1;SRVR:DB6PR0701MB2166;H:[10.144.127.200];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;DB6PR0701MB2166;23:QwpFo3baBXwWvsF3GCZB6nrL28gjWm3KMDW?= =?Windows-1252?Q?HzDi3jywQ/PltrDPtiyzPUKQW++DOseKKOpeh2Tf+rK6otPX4JfzoGlD?= =?Windows-1252?Q?YXBk9Xly1fwrgGh/Avfp8pSSaLyXNzjwilSDjBpYq4tzAVRWNWpj2Q8n?= =?Windows-1252?Q?0352hKaB+HZy14ONMdtikd7OL/IgoYPhYot2qUf1ExMCuNCU43hDn3dm?= =?Windows-1252?Q?oHgpYTDj7UDn210nxkbmsKluUC+j+Omb5MfJeBr3yNkYbYpC0bGb+NOW?= =?Windows-1252?Q?f1YH2ATQ/+zx+pUHDR6lHf+m/2Un3jdLpA1aYB5Q/m4dG65cnzwrVoki?= =?Windows-1252?Q?DAxPSz3sAgcdRlTzK1oV+OaZNQthWKPu5lJ6aF4Po5f6q5V1WkD09SSq?= =?Windows-1252?Q?1+Y+qyJ+LIRSotkeV4ASo6t2Ia9g1FwokInWGVEmyQAXgyvSpeAn219e?= =?Windows-1252?Q?02OIMSkybfV+7GOoGQTUoG6nQ80h30ZY61ZMRZ7cQLFQZbRaCpdUXmAJ?= =?Windows-1252?Q?9bp8+qHwjIlQZAeVOy34T/bOwj7FLlDHZLrds/d6cB5WuMSFfYGRHe3+?= =?Windows-1252?Q?Up/B5WvbZsMgJToArBjnJ1WscDNF7Oz5VRw0YTU3PyJQHS3Jg6QUTK79?= =?Windows-1252?Q?i3YRQKmZjAkuE58FWBQPragbIQNuBqdhCEBFB5KRw8uZ084HURa+vGUG?= =?Windows-1252?Q?du8QpYJEEuTSBkWIOh2cixqdiNG96GhjYLBo3qUtlpkKwmOS0WpMTfId?= =?Windows-1252?Q?6VC/LpTE0hT/ctiG5FVBXOlCImBaWt+Jfwmdutee3xh56vk8ufiSncEW?= =?Windows-1252?Q?mLf8GwRVSRB9JxearEl+dY3NjhnGJwOP0REqfsfK9PRzVFo0056sagRU?= =?Windows-1252?Q?kLovlKehslbyeZX1E8q15yNIQbmhRTz7wVXjurEXIJrlIXuS0vD1fMrv?= =?Windows-1252?Q?KTOd6f3tYKQahf/SlrUyk0XXvUxxu4W9oDEpeNR/dtnQzbS9arQZPBwv?= =?Windows-1252?Q?O+FIib/lKVCcFqf1CpxNmoLr7b2GoBs2jx5/++jgLfYNZ4zgV1Znpkph?= =?Windows-1252?Q?PGCLXpLchJFBPVDmbi0AiPdfPTjc18j7WbPGnYs6HcG3Vhsz9jL9v4em?= =?Windows-1252?Q?t5pf2LaRZ7DCX5e1AstM4pK7ZgYisT3ghJYcdM1C/b6LWh2t95w7iEcY?= =?Windows-1252?Q?0gP0b8cxiJBuhTA6Dcz7QaPwJNFMW8ABLigV6cpcv/T3AgRCdnJV9AeY?= =?Windows-1252?Q?HOxCwXpGmFnM++tp309WzqzuD/5++SrstvAuWE2ea4UmarIQztoQhX/A?= =?Windows-1252?Q?kIUhvZgrxA65h0rmwRrTdmrYR82b80GqVjy+JbDpmE2DC1RHwbLKWssl?= =?Windows-1252?Q?VRKpL5OdGbSOJNtYQTe25rEbc0h33dkqRl+EDWZ4JPm1FYYiCun7n8e4?= =?Windows-1252?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1;DB6PR0701MB2166;6:AwOV1fqhK2ODygysatQs0VBfi7C/bzn8n+bCljY+BJbC9YFHC/mT2rriigzGbNP9lsORBeQOm1HT1KCWyDUBcoRitZQwGiaa3dkx6l0xVJDlHyIMHuHWg1zdLKKmhf4NtSfNbTjEXhpYbTuAmGhDWWajS0qDIKes7kduWzpNHAy8a8NK9YSAy6gtEqDWZg8q6+DUCJw/8g5MPV9SGhSZ0l6iZqyIaueZQoZUYPErcV89npy9AOVvN6h9PuNVPcs+fkbOXjD3gShOdT9HIUN6uQdXXbjex2hRzjT7LWwJI6ZgwuD+nOlyD8+38EzfOxmjYiCCuQRKNNYDI0KKdfG0jA==;5:3EKh/FUuyGNVlPnWd4794bbg3pzv73NtEuIAgUEyQbn9Z27ku22nFDpoptKULHPvlbPieMAOtmUktd0VO6sc2MfCbDd9HsbU5px2Ftlwyo3nWKWeMtTNB7MMW5O1q5jgIRG40WKlpq18r8zLZv7/vA==;24:o6N3gY60x+8DufQWhTmI3ILHXg6IYvfCezsadqUFDiFZWLq9hJA0gNltlbsuZVNu2bA+36ne4SSlrhOU8Okj4V6ipmSpP4C83ramyVqHuGE=;7:KeC6UAG0/lHpOMN8LSMbkbV94o/FAgjvA4a5YMYcvXVHC5PIbs/cGF+D3u8on7soVQ2voU4OqCFs9mdSaCsZyVMPs6frf9cOeVkTAWq0PBGzQVcMoBVuAFcQ5gtkecZhSlvtoFTU3rVQlvwlheexWGyNMCzvdiJUAU9u6pzw2q9aQ0DG7OEsI7oVB2WB5GFTW8I1koqQ6s9NOSyjZ6SN5PkiWz+W3tJ70MMo85waoSfClYBAjq8/OQW6WqqjFRDj SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Aug 2016 12:33:52.9398 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2166 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/08/16 13:22, Jiri Olsa wrote: > On Tue, Aug 23, 2016 at 07:09:18AM +0200, Matija Glavinic Pecotic wrote: >> On 22/08/16 17:19, Jiri Olsa wrote: >>> should you also set following? >>> >>> *offset = ofs >>> dso->debug_frame_offset = ofs; >>> >>> I guess if we found the debuglink section with file having .debug_frame >>> section, we want to use it for this dso from now on.. >> >> I omitted this at first as I was thinking whether it is correct to do so. For >> our case, stripped dso, symbols in debug file, we are marking offset in other >> file, and not *this* dso. But I agree to you now, I have checked, and debug >> frame offset is not used anywhere, so it is a future problem. Someone might >> be surprised though that offset is marked, but for the other file. >> >>> I'd think let's have read_unwind_spec_debug_frame to find .debug_frame >>> and provide that info under dso object for subsequent reads >> >> Yes, that sounds. >> >>> so in case we find debuglink-ed file, it has precedence over the file >>> we found symtab in? assuming thats what dso->symsrc_filename is.. >> >> Thanks for pointing that one out, I haven't seen before we could use it. >> It was introduced with 0058aef65eda9c9dde8253af702d542ba7eef697 and it is >> aimed to keep name of the file with debug symbols, similar as needed here. >> >> I would then propose something like this below. This significantly changes >> dso__read_binary_type_filename, but I would say it wasn't proper before and >> it is not in sync with the rest of the cases in it. Idea of this function is >> to provide path to dso, and DSO_BINARY_TYPE__DEBUGLINK implies one location, >> which is not entirely correct. >> >> gdb and objcopy docs give points what debug link might be, and where debug >> file might reside. Debug link might be absolute path, or just name, in which >> case debug file should be looked up in several places. Here is what gdb does: >> >> So, for example, suppose you ask gdb to debug /usr/bin/ls, which has a debug >> link that specifies the file ls.debug, and a build ID whose value in hex is >> abcdef1234. If the list of the global debug directories includes >> /usr/lib/debug, then gdb will look for the following debug information files, >> in the indicated order: >> >> - /usr/lib/debug/.build-id/ab/cdef1234.debug >> - /usr/bin/ls.debug >> - /usr/bin/.debug/ls.debug >> - /usr/lib/debug/usr/bin/ls.debug. >> >> https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html >> https://sourceware.org/binutils/docs/binutils/objcopy.html >> >> Could you please tell me what are your thoughts on this kind of approach? >> >> --- >> tools/perf/util/dso.c | 40 ++++++++++++++++++++++++++++++++ >> tools/perf/util/unwind-libunwind-local.c | 28 +++++++++++++++++++++- >> 2 files changed, 67 insertions(+), 1 deletion(-) >> >> diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c >> index 774f6ec..ecc859e 100644 >> --- a/tools/perf/util/dso.c >> +++ b/tools/perf/util/dso.c >> @@ -46,11 +46,14 @@ int dso__read_binary_type_filename(const struct dso *dso, >> switch (type) { >> case DSO_BINARY_TYPE__DEBUGLINK: { >> char *debuglink; >> + char *dir; >> + char symfile[PATH_MAX]; >> >> len = __symbol__join_symfs(filename, size, dso->long_name); >> debuglink = filename + len; >> while (debuglink != filename && *debuglink != '/') >> debuglink--; >> + dir = debuglink; >> if (*debuglink == '/') >> debuglink++; >> >> @@ -60,8 +63,45 @@ int dso__read_binary_type_filename(const struct dso *dso, >> >> ret = filename__read_debuglink(filename, debuglink, >> size - (debuglink - filename)); >> + if (ret) >> + break; >> + >> + /* Check predefined locations where debug file might reside: >> + * - if debuglink is absolute path, check only that one >> + * If debuglink provides just name: >> + * - in the same directory as dso >> + * - in the .debug subdirectory of dso directory >> + * - in the /usr/lib/debug/[path to dso directory] >> + * */ >> + if (*debuglink == '/') { >> + ret = is_regular_file(debuglink); >> + break; >> + } >> + >> + snprintf(symfile, PATH_MAX, "%s/%s", dir, debuglink); >> + ret = is_regular_file(symfile); >> + if(!ret) { >> + strncpy(debuglink, symfile, size); >> + break; >> + } >> + >> + snprintf(symfile, PATH_MAX, "%s/.debug/%s", dir, debuglink); >> + ret = is_regular_file(symfile); >> + if(!ret) { >> + strncpy(debuglink, symfile, size); >> + break; >> + } >> + >> + snprintf(symfile, PATH_MAX, "/usr/bin/debug/%s/%s", dir, debuglink); >> + ret = is_regular_file(symfile); >> + if(!ret) { >> + strncpy(debuglink, symfile, size); >> + break; >> + } >> + >> } >> break; >> + >> case DSO_BINARY_TYPE__BUILD_ID_CACHE: >> if (dso__build_id_filename(dso, filename, size) == NULL) >> ret = -1; >> diff --git a/tools/perf/util/unwind-libunwind-local.c b/tools/perf/util/unwind-libunwind-local.c >> index 97c0f8f..a1d3c93 100644 >> --- a/tools/perf/util/unwind-libunwind-local.c >> +++ b/tools/perf/util/unwind-libunwind-local.c >> @@ -35,6 +35,7 @@ >> #include "util.h" >> #include "debug.h" >> #include "asm/bug.h" >> +#include "dso.h" >> >> extern int >> UNW_OBJ(dwarf_search_unwind_table) (unw_addr_space_t as, >> @@ -296,6 +297,8 @@ static int read_unwind_spec_debug_frame(struct dso *dso, >> { >> int fd; >> u64 ofs = dso->data.debug_frame_offset; >> + char *debuglink = malloc(PATH_MAX); >> + int ret = 0; >> >> if (ofs == 0) { >> fd = dso__data_get_fd(dso, machine); >> @@ -304,8 +307,31 @@ static int read_unwind_spec_debug_frame(struct dso *dso, >> >> /* Check the .debug_frame section for unwinding info */ >> ofs = elf_section_offset(fd, ".debug_frame"); >> - dso->data.debug_frame_offset = ofs; >> dso__data_put_fd(dso); >> + >> + if (!ofs) { >> + /* If not found, try to lookup in debuglink */ >> + ret = dso__read_binary_type_filename( >> + dso, DSO_BINARY_TYPE__DEBUGLINK, >> + machine->root_dir, debuglink, PATH_MAX); >> + if (!ret) { >> + fd = open(debuglink, O_RDONLY); >> + if (fd < 0) >> + return -EINVAL; >> + >> + ofs = elf_section_offset(fd, ".debug_frame"); >> + close(fd); >> + >> + if (ofs) { >> + dso->symsrc_filename = debuglink; > > symsrc_filename is initialized with file that has symtab, > which I'm not sure is guaranteed in here as well.. > > Namhyung, Massami? Yes, I see it. This file could also be debuglink, but that is not guaranteed. I would propose to look in symsrc_filename for .debug_frame. If its not there, we could still take a look into debuglink as a last resort. What I wonder, would it be fine in such a case to store debuglink to symsrc, if its already set? Though, this case is somewhat unlikely, but not entirely impossible Thanks, Matija > thanks, > jirka > >> + } >> + } >> + } >> + >> + pr_debug("%s: dso: %s, ret: %d, debuglink: <%s>\n", >> + __func__, dso->short_name, ret, debuglink); >> + >> + dso->data.debug_frame_offset = ofs; >> } >> >> *offset = ofs; >> -- >> 2.1.4 >> >>