Question concerning comment in symtab.h

Question concerning comment in symtab.h

[Paul N. Hilfinger]

The definition of struct block contains:

    /* Version of GCC used to compile the function corresponding
       to this block, or 0 if not compiled with GCC.  When possible,
       GCC should be compatible with the native compiler, or if that
       is not feasible, the differences should be fixed during symbol
       reading.  As of 16 Apr 93, this flag is never used to distinguish
       between gcc2 and the native compiler.

       If there is no function corresponding to this block, this meaning
       of this flag is undefined.  */

    unsigned char gcc_compile_flag;

Am I correct that this comment is wrong?  For example, in valops.c 
(hand_function_call), we find 

  {
    struct block *b = block_for_pc (funaddr);
    /* If compiled without -g, assume GCC 2.  */
    using_gcc = (b == NULL ? 2 : BLOCK_GCC_COMPILED (b));
  }

  ... and later ...

      if (using_gcc == 0)
	if (param_type)
	  /* if this parameter is a pointer to function */
	  if (TYPE_CODE (param_type) == TYPE_CODE_PTR)
	    if (TYPE_CODE (param_type->target_type) == TYPE_CODE_FUNC)
	      /* elz: FIXME here should go the test about the compiler used
	         to compile the target. We want to issue the error
	         message only if the compiler used was HP's aCC.

which looks to me as if it handles GCC 2 and native compilers differently.

[I ask because we may have another use for BLOCK_GCC_COMPILED, which simply
returns gcc_compile_flag, and I want to understand whether anything DEPENDS
on the assertion in this comment.]

Paul Hilfinger

Re: Question concerning comment in symtab.h

[Daniel Berlin]

On Wednesday, May 9, 2001, at 08:04 PM, Paul N. Hilfinger wrote:

>
> The definition of struct block contains:
>
>     /* Version of GCC used to compile the function corresponding
>        to this block, or 0 if not compiled with GCC.  When possible,
>        GCC should be compatible with the native compiler, or if that
>        is not feasible, the differences should be fixed during symbol
>        reading.  As of 16 Apr 93, this flag is never used to distinguish
>        between gcc2 and the native compiler.
>
>        If there is no function corresponding to this block, this meaning
>        of this flag is undefined.  */
>
>     unsigned char gcc_compile_flag;
>
> Am I correct that this comment is wrong?  For example, in valops.c
> (hand_function_call), we find
>
>   {
>     struct block *b = block_for_pc (funaddr);
>     /* If compiled without -g, assume GCC 2.  */
>     using_gcc = (b == NULL ? 2 : BLOCK_GCC_COMPILED (b));
>   }
>
>   ... and later ...
>
>       if (using_gcc == 0)
> 	if (param_type)
> 	  /* if this parameter is a pointer to function */
> 	  if (TYPE_CODE (param_type) == TYPE_CODE_PTR)
> 	    if (TYPE_CODE (param_type->target_type) == TYPE_CODE_FUNC)
> 	      /* elz: FIXME here should go the test about the compiler used
> 	         to compile the target. We want to issue the error
> 	         message only if the compiler used was HP's aCC.
>
> which looks to me as if it handles GCC 2 and native compilers 
> differently.
>
> [I ask because we may have another use for BLOCK_GCC_COMPILED, which 
> simply
> returns gcc_compile_flag, and I want to understand whether anything 
> DEPENDS
> on the assertion in this comment.]
What do you want to do with BLOCK_GCC_COMPILED?
I was just getting ready to remove it.
As the comment says, you shouldn't be using it to distinguish between 
gcc and something else past the symbol reading.

>
> Paul Hilfinger

Re: Question concerning comment in symtab.h

[Paul Hilfinger]

>   Date: Wed, 9 May 2001 20:21:26 -0400
>   From: Daniel Berlin <dan@cgsoftware.com>
>
>   On Wednesday, May 9, 2001, at 08:04 PM, Paul N. Hilfinger wrote:
>
>   >        ....  As of 16 Apr 93, this flag is never used to distinguish
>   >        between gcc2 and the native compiler.
>   >	    ...
>   >
>   >     unsigned char gcc_compile_flag;
>   >
>   > Am I correct that this comment is wrong?  ...
>   >
>   > [I ask because we may have another use for BLOCK_GCC_COMPILED, ...
>
>   What do you want to do with BLOCK_GCC_COMPILED?

It's a bit complicated, and since it also involves GCC, I don't have the 
complete story.  On the PA-RISC platform, GCC does not entirely conform to
HP's published material about stack unwinding information, as a result of
which there is some confusion for programs that use both GCC-compiled and
HP-native-compiled subprograms and that use alloca.  A complete fix to GCC
is (I'm told) rather involved.  For some period of time, therefore, we 
intend to also make some changes to GDB.  Whether these get into the 
public tree as is or are partially overtaken by events (i.e., changes to
GCC) remains to be seen.  However, in any case I need to understand what is 
going on.

>   I was just getting ready to remove it.
>   As the comment says, you shouldn't be using it to distinguish between 
>   gcc and something else past the symbol reading.

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)?

And, again, my original question: Is the "As of 16 Apr 93" comment above
indeed incorrect, or am I misunderstanding its intent?

P. Hilfinger

Re: Question concerning comment in symtab.h

[Daniel Berlin]

On Wed, 9 May 2001, Paul Hilfinger wrote:

>
> >   Date: Wed, 9 May 2001 20:21:26 -0400
> >   From: Daniel Berlin <dan@cgsoftware.com>
> >
> >   On Wednesday, May 9, 2001, at 08:04 PM, Paul N. Hilfinger wrote:
> >
> >   >        ....  As of 16 Apr 93, this flag is never used to distinguish
> >   >        between gcc2 and the native compiler.
> >   >	    ...
> >   >
> >   >     unsigned char gcc_compile_flag;
> >   >
> >   > Am I correct that this comment is wrong?  ...
> >   >
> >   > [I ask because we may have another use for BLOCK_GCC_COMPILED, ...
> >
> >   What do you want to do with BLOCK_GCC_COMPILED?
>
> 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.
It only matters for STABS, anyway. For DWARF2, it's always set to 2, and
i'm not sure about mdebug and xcoff.

>
> And, again, my original question: Is the "As of 16 Apr 93" comment above
> indeed incorrect, or am I misunderstanding its intent?
Technically, it's correct.  Or at least, it's supposed to be.
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.
 >
> P. Hilfinger
>

Re: Question concerning comment in symtab.h

[Paul Hilfinger]

   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?  

>   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?


P. Hilfinger

Re: Question concerning comment in symtab.h

[Daniel Berlin]

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
>

Re: Question concerning comment in symtab.h

[Elena Zannoni]

Paul N. Hilfinger writes:
 > 
 > The definition of struct block contains:
 > 
 >     /* Version of GCC used to compile the function corresponding
 >        to this block, or 0 if not compiled with GCC.  When possible,
 >        GCC should be compatible with the native compiler, or if that
 >        is not feasible, the differences should be fixed during symbol
 >        reading.  As of 16 Apr 93, this flag is never used to distinguish
 >        between gcc2 and the native compiler.
 > 
 >        If there is no function corresponding to this block, this meaning
 >        of this flag is undefined.  */
 > 
 >     unsigned char gcc_compile_flag;
 > 
 > Am I correct that this comment is wrong?  For example, in valops.c 
 > (hand_function_call), we find 
 > 
 >   {
 >     struct block *b = block_for_pc (funaddr);
 >     /* If compiled without -g, assume GCC 2.  */
 >     using_gcc = (b == NULL ? 2 : BLOCK_GCC_COMPILED (b));
 >   }
 > 
 >   ... and later ...
 > 
 >       if (using_gcc == 0)
 > 	if (param_type)
 > 	  /* if this parameter is a pointer to function */
 > 	  if (TYPE_CODE (param_type) == TYPE_CODE_PTR)
 > 	    if (TYPE_CODE (param_type->target_type) == TYPE_CODE_FUNC)
 > 	      /* elz: FIXME here should go the test about the compiler used
 > 	         to compile the target. We want to issue the error
 > 	         message only if the compiler used was HP's aCC.
 > 
 > which looks to me as if it handles GCC 2 and native compilers differently.
 > 

This code in valops.c was added to handle HP's native compiler. I am
really tempted to just remove it, because it breaks function calls
with function pointers as parameters for all the cases in which gcc is
not used. I am going to submit a patch to get rid of this code.

If I do that, I think the only remaining use of gcc_compile_flag
outside of the symbol readers is in generic_use_struct_convention in
values.c, and it is used to distinguish between different versions of
gcc (specifically 2.0 to 2.3.3, vs. all the others). I wonder if this
could be eliminated as well.


 > [I ask because we may have another use for BLOCK_GCC_COMPILED, which simply
 > returns gcc_compile_flag, and I want to understand whether anything DEPENDS
 > on the assertion in this comment.]
 > 
 > Paul Hilfinger
 > 

Elena

Re: Question concerning comment in symtab.h

[Paul Hilfinger]

>This code in valops.c was added to handle HP's native compiler. I am
>really tempted to just remove it, because it breaks function calls
>with function pointers as parameters for all the cases in which gcc is
>not used. I am going to submit a patch to get rid of this code.

>If I do that, I think the only remaining use of gcc_compile_flag
>outside of the symbol readers is in generic_use_struct_convention in
>values.c, and it is used to distinguish between different versions of
>gcc (specifically 2.0 to 2.3.3, vs. all the others). I wonder if this
>could be eliminated as well.

Well, as a matter of fact, I was grubbing around here precisely in
order to enhance support for debugging native-HP-compiled code---WHAT
an odd coincidence.  Are you saying you DON'T want to support HP-
native-compiled code, or are you saying that we should move to a better
approach?  If, as I hope, you mean the latter, could we agree on The
Right Way to do this?  The specific problem I am struggling with is
that GCC does not entirely conform to HP's ABI for stack-unwinding
info (specifically, it slightly misuses the SAVE_SP bit: see also
previous messages from me on this).

Paul Hilfinger

Re: Question concerning comment in symtab.h

[Daniel Berlin]

Paul Hilfinger <hilfingr@EECS.Berkeley.EDU> writes:

> >This code in valops.c was added to handle HP's native compiler. I am
> >really tempted to just remove it, because it breaks function calls
> >with function pointers as parameters for all the cases in which gcc is
> >not used. I am going to submit a patch to get rid of this code.
> 
> >If I do that, I think the only remaining use of gcc_compile_flag
> >outside of the symbol readers is in generic_use_struct_convention in
> >values.c, and it is used to distinguish between different versions of
> >gcc (specifically 2.0 to 2.3.3, vs. all the others). I wonder if this
> >could be eliminated as well.
> 
> Well, as a matter of fact, I was grubbing around here precisely in
> order to enhance support for debugging native-HP-compiled code---WHAT
> an odd coincidence.  Are you saying you DON'T want to support HP-
> native-compiled code, or are you saying that we should move to a better
> approach? 

The second, of course. I figured as much (that you wanted to improve
HP compiled code), too.  Maybe you know enough
about HP aCC to fix a problem in hpacc-abi.c (an unsubmitted version)
with figuring out virtual table location?

>  If, as I hope, you mean the latter, could we agree on The
> Right Way to do this?  The specific problem I am struggling with is
> that GCC does not entirely conform to HP's ABI for stack-unwinding
> info (specifically, it slightly misuses the SAVE_SP bit: see also
> previous messages from me on this).

Well, hmmm.
Can't we handle this in the symbol reader?


> 
> Paul Hilfinger

-- 
"My roommate got a pet elephant.  Then it got lost.  It's in the
apartment somewhere.
"-Steven Wright

Re: Question concerning comment in symtab.h

[Daniel Berlin]

Elena Zannoni <ezannoni@cygnus.com> writes:

> Paul Hilfinger writes:
>  > 
>  > >This code in valops.c was added to handle HP's native compiler. I am
>  > >really tempted to just remove it, because it breaks function calls
>  > >with function pointers as parameters for all the cases in which gcc is
>  > >not used. I am going to submit a patch to get rid of this code.
>  > 
>  > >If I do that, I think the only remaining use of gcc_compile_flag
>  > >outside of the symbol readers is in generic_use_struct_convention in
>  > >values.c, and it is used to distinguish between different versions of
>  > >gcc (specifically 2.0 to 2.3.3, vs. all the others). I wonder if this
>  > >could be eliminated as well.
>  > 
>  > Well, as a matter of fact, I was grubbing around here precisely in
>  > order to enhance support for debugging native-HP-compiled code---WHAT
>  > an odd coincidence.  Are you saying you DON'T want to support HP-
>  > native-compiled code, or are you saying that we should move to a better
>  > approach?  If, as I hope, you mean the latter, could we agree on The
>  > Right Way to do this?  The specific problem I am struggling with is
>  > that GCC does not entirely conform to HP's ABI for stack-unwinding
>  > info (specifically, it slightly misuses the SAVE_SP bit: see also
>  > previous messages from me on this).
>  > 
> 
> I wanted to get rid of the hack. I am not sure what the right way to
> provide that functionality is, at the moment. I don't know if the HP
> native compiler has changed since that code was put in. Do you know if
> that hack is still necessary? 
> [I wonder what HP's WDB does nowadays. Have you looked at that?]
> 
> If you look in hp-symtab-read.c, processing_gcc_compilation is set to
> 0, which is wrong, I think, because that file is used to process gcc
> compiled files as well as aCC compiled files.

Eerr, no, this is wrong. AFAIK, only HP's compiler produces that type
of debug info.

And they are moving to dwarf2 anyway, or at least, wanted to.
>   Does HP's compiler
> still use SOM? And what does gcc emit on hpux?  Note that there is
> another variable with a similar purpose, hp_som_som_object_present,
> maybe that could be unified/integrated with the function pointer
> hack.


> 
> I don't remember much about HP's stack layout, so I can't help much
> here, sorry. 
> 
> The HP platform is in pretty bad shape right now, any improvement
> would be good.
> 
> Elena
> 
>  > Paul Hilfinger
>  > 

-- 
"Do you think that when they asked George Washington for ID that
he just whipped out a quarter?
"-Steven Wright

Re: Question concerning comment in symtab.h

[Elena Zannoni]

Daniel Berlin writes:
 > Elena Zannoni <ezannoni@cygnus.com> writes:
 > 
 > > Paul Hilfinger writes:
 > >  > 
 > >  > >This code in valops.c was added to handle HP's native compiler. I am
 > >  > >really tempted to just remove it, because it breaks function calls
 > >  > >with function pointers as parameters for all the cases in which gcc is
 > >  > >not used. I am going to submit a patch to get rid of this code.
 > >  > 
 > >  > >If I do that, I think the only remaining use of gcc_compile_flag
 > >  > >outside of the symbol readers is in generic_use_struct_convention in
 > >  > >values.c, and it is used to distinguish between different versions of
 > >  > >gcc (specifically 2.0 to 2.3.3, vs. all the others). I wonder if this
 > >  > >could be eliminated as well.
 > >  > 
 > >  > Well, as a matter of fact, I was grubbing around here precisely in
 > >  > order to enhance support for debugging native-HP-compiled code---WHAT
 > >  > an odd coincidence.  Are you saying you DON'T want to support HP-
 > >  > native-compiled code, or are you saying that we should move to a better
 > >  > approach?  If, as I hope, you mean the latter, could we agree on The
 > >  > Right Way to do this?  The specific problem I am struggling with is
 > >  > that GCC does not entirely conform to HP's ABI for stack-unwinding
 > >  > info (specifically, it slightly misuses the SAVE_SP bit: see also
 > >  > previous messages from me on this).
 > >  > 
 > > 
 > > I wanted to get rid of the hack. I am not sure what the right way to
 > > provide that functionality is, at the moment. I don't know if the HP
 > > native compiler has changed since that code was put in. Do you know if
 > > that hack is still necessary? 
 > > [I wonder what HP's WDB does nowadays. Have you looked at that?]
 > > 
 > > If you look in hp-symtab-read.c, processing_gcc_compilation is set to
 > > 0, which is wrong, I think, because that file is used to process gcc
 > > compiled files as well as aCC compiled files.
 > 
 > Eerr, no, this is wrong. AFAIK, only HP's compiler produces that type
 > of debug info.

Ok, so what does gcc produces on HPUX?

 > 
 > And they are moving to dwarf2 anyway, or at least, wanted to.

Yeah, but we should keep some degree of backwards compatibility.

Thanks
Elena

 > >   Does HP's compiler
 > > still use SOM? And what does gcc emit on hpux?  Note that there is
 > > another variable with a similar purpose, hp_som_som_object_present,
 > > maybe that could be unified/integrated with the function pointer
 > > hack.
 > 
 > 
 > > 
 > > I don't remember much about HP's stack layout, so I can't help much
 > > here, sorry. 
 > > 
 > > The HP platform is in pretty bad shape right now, any improvement
 > > would be good.
 > > 
 > > Elena
 > > 
 > >  > Paul Hilfinger
 > >  > 
 > 
 > -- 
 > "Do you think that when they asked George Washington for ID that
 > he just whipped out a quarter?
 > "-Steven Wright
 >