From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11137 invoked by alias); 21 Nov 2013 17:39:52 -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 11116 invoked by uid 89); 21 Nov 2013 17:39:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FROM_12LTRDOM,RDNS_NONE autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from Unknown (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Nov 2013 17:39:50 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VjYE2-0002ZB-Ku from Luis_Gustavo@mentor.com ; Thu, 21 Nov 2013 09:39:34 -0800 Received: from NA1-MAIL.mgc.mentorg.com ([147.34.98.181]) by svr-orw-fem-01.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Nov 2013 09:39:34 -0800 Received: from [172.30.4.200] ([172.30.4.200]) by NA1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Nov 2013 09:39:33 -0800 Message-ID: <528E454F.6060003@codesourcery.com> Date: Thu, 21 Nov 2013 17:39:00 -0000 From: Luis Machado Reply-To: lgustavo@codesourcery.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "gdb@sourceware.org" , Tom Tromey , "Maciej W. Rozycki" Subject: Unreliable BFD caching heuristic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00080.txt.bz2 Hi, Just recently i was chasing a bug in an automated GCC testing environment that uses GDB to run the programs GCC builds. Some tests in GCC's testsuite create a number of different binaries with the same name, one after the other, with different flags. The bug happens when GDB loads all of those binaries, one at a time obviously, in a single session, with a pattern of loading, running, loading, running... That's when the BFD caching takes effect and starts trying to save resources based on two pieces of information: file name and the file's modification timestamp. In summary, if you are using a reasonably fast build system that can create multiple binaries per second, you can potentially end up with two or more binaries with the same file modification timestamp. If all those things happen at the same time, the BFD machinery will attempt to use a cached entry to load data from a totally new binary. From that point onwards, things just go downhill. This is really a regression compared to older GDB's, and a solution probably involves improving the matching heuristics, in gdb/gdb_bfd.c:eq_bfd, with more data. Experiments show that using the file size in eq_bfd helps a little, but i've managed to trigger the bug with that as well, plus it does not address the problem of having multiple BFD's inside an archive. Since we have hash functions available, Maciej (cc-ed) suggested creating a hash number based on ELF header information, which sounds like a good approach. I can also see how this bug would happen under systems with low resolution timestamps or with filesystems that do not provide precise timestamp information. Do you have any proposals on ways to improve this heuristic? As an example, here is a list of binaries GCC generates for a testcase (with unique names so we can compare them side-by-side). Notice their timestamps. Size Timestamp Name 107223 2013-11-20 19:53:01.758737300 -0800 20020220-1-10.exe 106727 2013-11-20 19:53:01.758737300 -0800 20020220-1-11.exe 106727 2013-11-20 19:53:01.758737300 -0800 20020220-1-12.exe 107303 2013-11-20 19:53:01.758737300 -0800 20020220-1-13.exe 106727 2013-11-20 19:53:02.258781643 -0800 20020220-1-14.exe 106727 2013-11-20 19:53:02.258781643 -0800 20020220-1-15.exe 107303 2013-11-20 19:53:02.258781643 -0800 20020220-1-16.exe 106727 2013-11-20 19:53:02.258781643 -0800 20020220-1-17.exe 106727 2013-11-20 19:53:02.757667981 -0800 20020220-1-18.exe 107575 2013-11-20 19:53:02.757667981 -0800 20020220-1-19.exe 107079 2013-11-20 19:53:02.757667981 -0800 20020220-1-20.exe 107079 2013-11-20 19:53:02.757667981 -0800 20020220-1-21.exe 107655 2013-11-20 19:53:02.757667981 -0800 20020220-1-22.exe 107079 2013-11-20 19:53:02.757667981 -0800 20020220-1-23.exe 107079 2013-11-20 19:53:02.757667981 -0800 20020220-1-24.exe 107655 2013-11-20 19:53:03.258763445 -0800 20020220-1-25.exe 107079 2013-11-20 19:53:03.258763445 -0800 20020220-1-26.exe 107079 2013-11-20 19:53:03.258763445 -0800 20020220-1-27.exe 104930 2013-11-20 19:53:01.258799713 -0800 20020220-1-2.exe 104962 2013-11-20 19:53:01.258799713 -0800 20020220-1-3.exe 105890 2013-11-20 19:53:01.258799713 -0800 20020220-1-4.exe 105170 2013-11-20 19:53:01.258799713 -0800 20020220-1-5.exe 105218 2013-11-20 19:53:01.258799713 -0800 20020220-1-6.exe 116934 2013-11-20 19:53:01.758737300 -0800 20020220-1-7.exe 116214 2013-11-20 19:53:01.758737300 -0800 20020220-1-8.exe 116270 2013-11-20 19:53:01.758737300 -0800 20020220-1-9.exe 105378 2013-11-20 19:52:57.758767853 -0800 20020220-1.exe Regards, Luis