From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94414 invoked by alias); 17 Sep 2016 17:25:08 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 94389 invoked by uid 89); 17 Sep 2016 17:25:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=H*r:2002, H*r:sk:gdb@sou, organizing, H*MI:shack X-HELO: moltke.seatribe.se Received: from moltke.seatribe.se (HELO moltke.seatribe.se) (178.63.100.209) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 17 Sep 2016 17:25:05 +0000 Received: from [2002:2f8:a79::1] (helo=nerv.dolda2000.com) by moltke.seatribe.se with esmtp (Exim 4.80) (envelope-from ) id 1blJMM-00056f-KW for gdb@sourceware.org; Sat, 17 Sep 2016 19:25:02 +0200 Received: from [2002:2f8:a79:200:d63d:7eff:feb4:da50] ([IPv6:2002:2f8:a79:200:d63d:7eff:feb4:da50]) (authenticated bits=0) by nerv.dolda2000.com (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u8HHOxGO000897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 17 Sep 2016 19:24:59 +0200 Date: Sat, 17 Sep 2016 17:25:00 -0000 From: Fredrik Tolf To: gdb@sourceware.org Subject: Bad performance in updating JIT debug symbols Message-ID: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SW-Source: 2016-09/txt/msg00048.txt.bz2 Dear list, I'm currently developing a library that uses LLVM to JIT-compile code into the running process every now and then. It happens fairly often, but in completely independent batches, so I'm racking up a fair number of LLVM modules, usually in the thousands, but at the very least in the hundreds. Whenever a new module is compiled, LLVM uses GDB's JIT-compiler interface to register the debug symbols for the module, which is pretty nice, but as the modules pile up, this is becoming very slow. In the end, it starts taking multiples of tens of milliseconds per new module, and since they usually come in several at once, GDB starts causing delays of a second or longer, which is pretty annoying when debugging. Debugging GDB in the process, it appears that it's stuck in the sorting phase of update_section_map(), and the place where it's spending all the time is the part of qsort_cmp() which, according to the comments, "could be slow (since we iterate over all objfiles in each call to qsort_cmp), but this shouldn't happen very often (GDB is already in a confused state; one hopes this doesn't happen at all)." Which obviously raises the question why it happens at all. I haven't decoded enough of GDB's source code yet to tell what it's really trying to do, but the reason for the slowness appears to be related to how the code and debug sections are organized together, so I'm wondering if this should be considered a bug in LLVM for organizing them incorrectly. Thoughts? -- Fredrik Tolf