Re: Question concerning comment in symtab.h

[Daniel Berlin <dan@www.cgsoftware.com>]

On Thu, 10 May 2001, Paul Hilfinger wrote:

>
>    Date: Thu, 10 May 2001 00:20:22 -0400 (EDT)
>    From: Daniel Berlin <dan@www.cgsoftware.com>
>
> >   > 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
>