From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Paul Hilfinger Cc: Subject: Re: Question concerning comment in symtab.h Date: Wed, 09 May 2001 23:33:00 -0000 Message-id: References: <20010510053353.41B0FF28A4@nile.gnat.com> X-SW-Source: 2001-05/msg00140.html On Thu, 10 May 2001, Paul Hilfinger wrote: > > Date: Thu, 10 May 2001 00:20:22 -0400 (EDT) > From: Daniel Berlin > > > > Right, and that's our intention. So, during symbol reading, one is now > > > supposed to reference gcc_compile_flag directly (and not reference it at > > > all elsewhere)? > > You mean proceessing_gcc_compilation. This is what BLOCK_GCC_COMPILED gets > > set to. > > Actually, I *did* mean gcc_compile_flag, which is what BLOCK_GCC_COMPILED > is, but now I understand what you mean. > > > It only matters for STABS, anyway. For DWARF2, it's always set to 2, and > > i'm not sure about mdebug and xcoff. > > I'm glad I brought this thread up, because now it's clear that I'm confused. > If BLOCK_GCC_COMPILED is always 2 for DWARF2, then the current comments imply > that only GCC produces DWARF2 (because a native compiler is supposed to set > gcc_compile_flag, and thus BLOCK_GCC_COMPILED to 0). Is that true? Whether it's still true, i couldn't tell you. I know that on MIPS, SGI's compilers producce dwarf2, and GCC on mips produces slightly different dwarf2 info than normal in order to be compatible with dbx (DWARF2.0 has some ambiguities that nobody realized at the time. The only difference i can actually remember their being, besides the extra info we omit on other platforms sincce gdb didn't use it, is in the array bounds specification). Almost every compiler vendor i know of (Intel, Compaq, Fujitsu, the portland group, etc) uses dwarf2 wherever the debug format isn't already locked in for other reasons. If you search through the comp.compilers archives for optimized code debugging, you'll see quite a few people mention that dwarf2 can do it, but that they never expect to see compilers producing dwarf2 on pc class machines. So it was certainly a reasonable expectation at the time, although now shown to be not so much anymore. In other words, nobody's bitched about structure returns with dwarf2 info yet, so it hasn't been fixed, because nobody's tickled all the right conditions. I'd need a test case to work with to get all the code right anyway. > > Do all the hacks necessary in the symbol readers, unless it's literally > > impossible. > > Heck, i'd rather see someone have to add a field to the type structure to > > or symbol structure to handle a difference, then introduce hacks into > > hand_function_call or something. > > I could just wait for the patch, but out of curiosity, how are you now > going to handle the last argument of using_struct_return? Here's a long answer: This can be done through a simple abstraction layer. I was going to add a struct to implement compiler related abstractions, such as this one, and throw one pointer to the struct per objfile. Then, for native/gcc compiler differences, or even gcc version differences, you just fill in the struct pointers to functions that do the right thing for that particular compiler, on this particular host. As you can tell, I'm against things like the gcc_p flags to using_struct_return. It's putting the knowledge in the wrong place, and doing it in the wrong way to boot. But anyway, ... > > > P. Hilfinger >