From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22526 invoked by alias); 22 Aug 2002 06:51:44 -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 22498 invoked from network); 22 Aug 2002 06:51:41 -0000 Received: from unknown (HELO devserv.devel.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 22 Aug 2002 06:51:41 -0000 Received: from localhost (alexl@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) with ESMTP id g7M6peZ31041; Thu, 22 Aug 2002 02:51:40 -0400 X-Authentication-Warning: devserv.devel.redhat.com: alexl owned process doing -bs Date: Wed, 21 Aug 2002 23:51:00 -0000 From: Alexander Larsson X-X-Sender: alexl@devserv.devel.redhat.com To: Jim Blandy cc: gdb@sources.redhat.com Subject: Re: External debug symbols In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-08/txt/msg00256.txt.bz2 On 21 Aug 2002, Jim Blandy wrote: > 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. Since I don't know much about the gdb codebase I tried to look for the solution that required the smallest amount of changes. But yeah, I was also a bit amazed how easy it was. > 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. It does sound nice, but it also sounds like an load of work. And for us having just one file with debug information per lib/executable is actually preferable, from a packagaging perspective. > 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 will change that. > 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. The later problem could be fixed by having a back-pointer from the debug objfile to the original one, and NULLing out the other pointer when the debug objfile is freed. The first issue sounds harder. It could be handled by making sure the debug file is always in front of the original file in the object_files list. But that sounds somewhat fragile. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a notorious chivalrous cowboy on his last day in the job. She's a disco-crazy paranoid vampire looking for love in all the wrong places. They fight crime!