From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114408 invoked by alias); 7 May 2015 22:52:34 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 114399 invoked by uid 89); 7 May 2015 22:52:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-oi0-f48.google.com Received: from mail-oi0-f48.google.com (HELO mail-oi0-f48.google.com) (209.85.218.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 07 May 2015 22:52:32 +0000 Received: by oift201 with SMTP id t201so45801097oif.3 for ; Thu, 07 May 2015 15:52:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=PmoM81W+aBtdWOEQH3eMeo2z3sMwwSw3ydPsLQiMlfk=; b=Amye/MNWyb2YOEnkGsjxFrm4s+7SqqW+PvAu4I6Dyc4FPQEufyToMuU6dpNRS3JoPj yAld/7mz6lQZI4FvcJf8KgPJ1OZ+9aF+eFg7mrX2jSpIP2Gz9xKZsCTCl25B/Tqv/Jhz VcR0dkFt82ihqrFGCicEHkklJ9lRhzy9fY5eMwWpzY9zVf6hnrLe4fiUgBJfSJJbyREv 0ZPhYY8AVkyHU7oE33jNO62u2l90FqWR5/7eWSNkW318GxskYS6TfDI2fWm807Cz6ZI2 /R2KiTmgi2FuuNxolO+yWAFi+4JqBeMdazYA31pUaoI1rp7BWZjqe0zWU1HEMNVTIafp ifcA== X-Gm-Message-State: ALoCoQk/493DtWY6JIdRJnfL3AVR9CcFIpXAxYD7qFyClQMH5hoMrvvUTpdkK47Y7Vzw2mvlPERn MIME-Version: 1.0 X-Received: by 10.182.134.169 with SMTP id pl9mr816058obb.32.1431039150184; Thu, 07 May 2015 15:52:30 -0700 (PDT) Received: by 10.182.89.99 with HTTP; Thu, 7 May 2015 15:52:30 -0700 (PDT) In-Reply-To: <90e6ba6e87129285600515847ec6@google.com> References: <90e6ba6e87129285600515847ec6@google.com> Date: Thu, 07 May 2015 22:52:00 -0000 Message-ID: Subject: Re: [RFC] When can we remove Sun-specific stabs support? (when will it be ok to delete partial_symtab.section_offsets?) From: Doug Evans To: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00170.txt.bz2 On Thu, May 7, 2015 at 2:21 PM, Doug Evans wrote: > Hi. > > While working on improving some symbol table code I stumbled on > partial_symtab.section_offsets and that led me to elfstab_offset_sections. > > AFAICT, the only reason partial_symtab.section_offsets exists is for > Sun stabs. There are no regressions if I comment out > elfstab_offset_sections on linux+stabs. > Grep for Ddata.data in doc/stabs.texinfo for further background. > > elfread.c: > > /* When handling an ELF file that contains Sun STABS debug info, > some of the debug info is relative to the particular chunk of the > section that was generated in its individual .o file. E.g. > offsets to static variables are relative to the start of the data > segment *for that module before linking*. This information is > painfully squirreled away in the ELF symbol table as local symbols > with wierd names. Go get 'em when needed. */ > > dbxread.c: > > #ifdef HAVE_ELF > /* If we're handling an ELF file, drag some section-relocation info > for this source file out of the ELF symbol table, to compensate for > Sun brain death. This replaces the section_offsets in this psymtab, > if successful. */ > elfstab_offset_sections (objfile, result); > #endif > > N.B. I'm not suggesting remove stabs support, just this hack for Sun stabs. > > Deleting partial_symtab.section_offsets will simplify some code > (for non-sun-stabs it's just a pointer to objfile->section_offsets). > It'll also help the ObjfileSplitting project. > https://sourceware.org/gdb/wiki/ObjfileSplitting Heh. Gotta love single stepping through code to see what's REALLY going on. I found this testcase in gas and hacked it to compile on x86. gas/testsuite/gas/sparc-solaris/sol-cc.s I then walked through gdb to verify it was properly handling this hack for Sun stabs. But when I get to elfstab_offset_sections, sectinfo is NULL so there is nothing to do. From the testcase clearly that's wrong. struct stab_section_info *maybe = dbx->stab_section_info; (top-gdb) p maybe $17 = (struct stab_section_info *) 0x0 It turns out the data is being freed before elfstab_offset_sections is called! elf_read_minimal_symbols has this: make_cleanup (free_elfinfo, (void *) objfile); and free_elfinfo is this: static void free_elfinfo (void *objp) { struct objfile *objfile = (struct objfile *) objp; struct dbx_symfile_info *dbxinfo = DBX_SYMFILE_INFO (objfile); struct stab_section_info *ssi, *nssi; ssi = dbxinfo->stab_section_info; while (ssi) { nssi = ssi->next; xfree (ssi); ssi = nssi; } dbxinfo->stab_section_info = 0; /* Just say No mo info about this. */ } So this hack is currently a no-op: we collect the needed info here: elfread.c: if (strcmp ("Bbss.bss", sym->name) == 0) special_local_sect = SECT_OFF_BSS (objfile); else if (strcmp ("Ddata.data", sym->name) == 0) special_local_sect = SECT_OFF_DATA (objfile); else if (strcmp ("Drodata.rodata", sym->name) == 0) special_local_sect = SECT_OFF_RODATA (objfile); and then throw it away (in free_elfinfo) before we use it (in elfstab_offset_sections). IIUC, and assuming I'm not missing anything, this has been broken since at least gdb 7.0 (I didn't check back any further). The code was a little different back then, but the free_elfinfo cleanup was still done before building psymtabs. Sufficient motivation for deleting this code now?