From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30889 invoked by alias); 13 May 2002 13:59:54 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30881 invoked from network); 13 May 2002 13:59:52 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 13 May 2002 13:59:52 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 177GMg-0004BU-00; Mon, 13 May 2002 09:59:50 -0400 Date: Mon, 13 May 2002 06:59:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Type cleanups Message-ID: <20020513135950.GB19484@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20020513003359.GA11672@nevyn.them.org> <3CDF3081.1020900@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CDF3081.1020900@cygnus.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-05/txt/msg00455.txt.bz2 On Sun, May 12, 2002 at 11:18:25PM -0400, Andrew Cagney wrote: > >In order to fix gdb/277, I needed to move a lot of members of 'struct > >type'. This patch flushes out all (that I could find) direct accesses of > >these > >members instead of through the proper macros. It's possible that I missed > >some; if so, the next patch will cause whichever files I missed to stop > >compiling. I'm pretty sure I got them all, though. I also clean up the > >only remaining references to 'sizeof (struct type)': dstread.c had a clone > >of alloc_type, and hpread.c needed to call replace_type like the other > >readers. > > > >This patch should have no effect. On i386-linux, I get byte-for-byte > >identical GDB binaries (all 5591185 bytes of it, debugging information > >and all; no -g3 here). > > > >OK to commit? > > Did you check all the cross targets build per MAINTAINERS? From memory > sh-hms[bfd] and avr[need to look] don't build at present (well as of > ~2002-05-12-gmt). > > If that has been checked, then yes ``obviously''. A few don't build; none of them are my fault. For the record: At least fr30-elf, mn10300-elf, and v850-elf have missing dependencies off in sim/ land; they built with non-parallel make only. hppa1.1-hp-proelf wants dl.h and machine/save_state.h in hppa-tdep.c, and was already marked broken. The nice gawk segment doesn't notice that... Several targets (i586-pc-msdosdjgpp, sparc-elf, sparc64-elf) failed with this message (also JB_SP for Sparc): In file included from /usr/include/setjmp.h:30, from ../../src-build/gdb/top.c:58: /usr/include/bits/setjmp.h:31: warning: `JB_PC' redefined tm.h:57: warning: this is the location of the previous definition make[1]: *** [top.o] Error 1 sh-hms failed with a reference to some new SHmedia code. x86-64 failed with: libgdb.a(solib.o): In function `clear_solib': /opt/src/gdb/crossbuild/obj.x86_64-linux-gnu/gdb/../../src-build/gdb/solib.c:742: undefined reference to `disable_breakpoints_in_shlibs' libgdb.a(solib-svr4.o): In function `enable_break': /opt/src/gdb/crossbuild/obj.x86_64-linux-gnu/gdb/../../src-build/gdb/solib-svr4.c:856: undefined reference to `remove_solib_event_breakpoints' /opt/src/gdb/crossbuild/obj.x86_64-linux-gnu/gdb/../../src-build/gdb/solib-svr4.c:983: undefined reference to `create_solib_event_breakpoint' Is x86-64 really "maintenance only"? Anyway, committed. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer