From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29065 invoked by alias); 21 Aug 2002 17:46:28 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 29055 invoked from network); 21 Aug 2002 17:46:26 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by sources.redhat.com with SMTP; 21 Aug 2002 17:46:26 -0000 Received: (from jimb@localhost) by zenia.red-bean.com (8.11.6/8.11.6) id g7LHZf003819; Wed, 21 Aug 2002 12:35:41 -0500 To: Alexander Larsson Cc: gdb@sources.redhat.com Subject: Re: External debug symbols References: From: Jim Blandy Date: Wed, 21 Aug 2002 10:46:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-08/txt/msg00251.txt.bz2 Wow, that's a lot less work than I expected it to be. It doesn't look especially wrong to me. Basically, the presence of a .debuglink section tells GDB that, whenever it loads one objfile, it should also load the other. When the stripped objfile is freed, the other one is freed, too. Sun's toolchain, I'm told, has the ability to simply leave the debug info in the .o files, and just put what amounts to an index in the executable file. The debugger is responsible for figuring out which .o file has the data it needs, and applying any relocs to the debug info based on the symbol values in the linked executable. This makes linking a lot faster, and keeps executables small. This would also address your distribution size problem, but it would also be helpful to developers in their everyday work as well. But since the .debuglink change is so simple, it seems a shame to put that on hold in favor of an alternative solution which I expect will take a lot more work, and may never get done. .debuglink looks like a Dwarf 2 section name. How about .gnu_debuglink? I'm also concerned about the deallocation policy. I think your change will break the ALL_OBJFILES_SAFE macro, since the `nxt' pointer the macro carefully caches before evaluating the `for' body will become invalid if the body goes and frees the objfile it points to. Along similar lines --- what would happen if the debug objfile gets unloaded before the stripped objfile? Wouldn't the stripped objfile still have a dangling pointer to the now-gone debug objfile? I can't think of a situation where this would happen, but it would be nice to be confident that it didn't matter. Alexander Larsson writes: > Hi > > I've been experimenting some with removing debug information from binaries > and placing it in a separate file, and then having gdb automatically load > these if availible. (The goal here is to package debug information in > separate packages that can be on-demand downloaded and installed.) > > I have written a libelf based application that takes an elf file, splits > out debug information to a separate file, strips the original file and > adds a ".debuglink" section to the stripped file. This section contains > the basename of the filename of the debug file and a crc32 checksum of it. > > I've also written an "unstrip" application that puts together the original > ELF file from the stripped one and the debug file (and some extra > information I put in a section of the debug file). This produces a bitwise > identical file to the original. > > My next step is to make gdb automatically follow ".debuglink" sections so > that i don't have to use the unstrip application. Attached to this mail is > a patch that implements a "badhack" which seems to almost work. In order > for it to work I had to add all the original section headers to the debug > file (but SHT_NOBITS, so they take no space). It seems to work for the > main binary, but setting breakpoints in libraries doesn't work. I think it > gets the base address wrong or something. > > What are your opinions about this solution? Has anything like this been > done or tought of before? I'm pretty scared of the gdb codebase (looked at > it for the first time today), so my solution is probably both buggy and > generally wrong, tips of other ways to do this are appreciated. > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl@redhat.com alla@lysator.liu.se > He's a benighted Jewish romance novelist plagued by the memory of his family's > brutal murder. She's a time-travelling Bolivian traffic cop with only herself > to blame. They fight crime!