From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: "Zack Weinberg" Cc: Daniel Berlin , Mark Mitchell , gcc-patches@gcc.gnu.org, Jim Wilson Subject: Re: killing ASM_IDENTIFY_GCC [branch] Date: Wed, 11 Apr 2001 06:28:00 -0000 Message-id: References: <20010410222316.A221@stanford.edu> <20010410231659H.mitchell@codesourcery.com> <20010411004540.C221@stanford.edu> X-SW-Source: 2001-04/msg00610.html "Zack Weinberg" writes: > On Wed, Apr 11, 2001 at 02:34:47AM -0400, Daniel Berlin wrote: > > Mark Mitchell writes: > > > > > I'm not qualified to review this patch since there are too many funky > > > targets I don't know about. > > > > This patch will break STABS in gdb. > > Can you expand a bit more? I remember you saying that it didn't use > gcc2_compiled. at all. A little more investigation shows I missed the small part of the source that sets the value of a global variable that *is* used (because it's really in dbxread.c, not stabsread.c, where one would expect it). > > ... > > There is a lot of annoying stuff in processing STABS in gdb. I > > could work around most of it by saying "if we aren't on a sun, and > > we have STABS debug info, we are processing gcc compiled stuff" > > (since it's sun's dbx stuff that all these problems/workarounds are > > implemented for). However, I can't do this unless the sun ones are > > moved to DWARF2 as the default with this change as well (so that > > stabs no longer occurs, and stabs that does occur will have the > > symbol, or be sun compiled stuff). Unless Sun's compiler also > > outputs gcc2_compiled these days, i don't know. > > Also I'm failing to see why it matters which compiler generated the > STABS information. I thought that GCC tried to match what the native > compiler generated. grep stabsread.c and dbxread.c for processing_gcc_compilation. There are a few small, but somewhat important differences, in where the info is getting placed, and how it gets processed. > > zw -- I was once arrested for walking in someone else's sleep.