Bootstrapping hppa64? CPP problem

Bootstrapping hppa64? CPP problem

[Steve Ellcey]

I am curious if anyone is currently bootstrapping the hppa64 GCC
compiler from the latest sources?  I am running into a very curious cpp
problem.  With the attached example, using the cc1 that I just built I
get two definitions of sigpause showing up because _SVID2 seems to be
considered defined and undefined at the same time.  It doesn't happen on
the other platforms I have tried but it happens consistenly for me on
PA64.

Steve Ellcey
sje@cup.hp.com

[hpsje - sje_pa64] $ cat x.c
#define _SVID2

#if !defined(_SVID2)
     extern long sigpause(long);
#endif

#if defined(_SVID2)
           extern int sigpause(int);
#endif

--------------------------------

[hpsje - sje_pa64] $ obj_pa64_gcc/gcc/cc1 -E -quiet x.c
# 1 "x.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "x.c"



     extern long sigpause(long);



           extern int sigpause(int);

Re: Bootstrapping hppa64? CPP problem

[Zack Weinberg]

On Wed, Jul 10, 2002 at 03:54:18PM -0700, Steve Ellcey wrote:
> I am curious if anyone is currently bootstrapping the hppa64 GCC
> compiler from the latest sources?  I am running into a very curious cpp
> problem.  With the attached example, using the cc1 that I just built I
> get two definitions of sigpause showing up because _SVID2 seems to be
> considered defined and undefined at the same time.  It doesn't happen on
> the other platforms I have tried but it happens consistenly for me on
> PA64.

As Jeff points out, this is a memory corruption bug.  I have attempted
to reproduce the problem with an x86 host (native, and cross-compiling
to pa64) without success; I do not currently have access to any other
host.

Do you have a Purify license?  It should be able to catch the
underlying bug.  Unfortunately, the only free-software near equivalent
I know of (valgrind) is x86 specific, and shows no invalid memory
accesses when applied to your test case.

zw

Re: Bootstrapping hppa64? CPP problem

[Neil Booth]

Steve Ellcey wrote:-

> I am curious if anyone is currently bootstrapping the hppa64 GCC
> compiler from the latest sources?  I am running into a very curious cpp
> problem.  With the attached example, using the cc1 that I just built I
> get two definitions of sigpause showing up because _SVID2 seems to be
> considered defined and undefined at the same time.  It doesn't happen on
> the other platforms I have tried but it happens consistenly for me on
> PA64.
> 
> Steve Ellcey
> sje@cup.hp.com
> 
> [hpsje - sje_pa64] $ cat x.c
> #define _SVID2
> 
> #if !defined(_SVID2)
>      extern long sigpause(long);
> #endif
> 
> #if defined(_SVID2)
>            extern int sigpause(int);
> #endif

Steve,

Could you step into the code (should be not too hard to grok
for such a simple case) starting with the #define and see
what hash entry pointer is given for _SVID2?  Then figure
out why you're not getting it for the !defined line?

A breakpoint on do_define() might be useful; be sure to
step into lex_macro_node () which lexes and creates a hash
entry for _SVID2.  If this is a CPP bug I would really like
to catch it.

Neil.

Re: Bootstrapping hppa64? CPP problem

[Neil Booth]

Neil Booth wrote:-

> Steve,
> 
> Could you step into the code (should be not too hard to grok
> for such a simple case) starting with the #define and see
> what hash entry pointer is given for _SVID2?  Then figure
> out why you're not getting it for the !defined line?
> 
> A breakpoint on do_define() might be useful; be sure to
> step into lex_macro_node () which lexes and creates a hash
> entry for _SVID2.  If this is a CPP bug I would really like
> to catch it.

Hmm, not such good advice - do_define is called for the built-ins
too.

If -undef also exhibits the bug, you could try it as described
above, otherwise break on _cpp_handle_directive before setting
the do_define breakpoint.  That way you'll avoid a dozen or so
built-ins.

Neil.

Re: Bootstrapping hppa64? CPP problem

[John David Anglin]

> I am curious if anyone is currently bootstrapping the hppa64 GCC
> compiler from the latest sources?  I am running into a very curious cpp
> problem.  With the attached example, using the cc1 that I just built I
> get two definitions of sigpause showing up because _SVID2 seems to be
> considered defined and undefined at the same time.  It doesn't happen on
> the other platforms I have tried but it happens consistenly for me on
> PA64.

I filed a PR for the exact same problem on vax-dec-ultrix4.3.  However,
I couldn't duplicate it with a cross compiler.  It appears '!' isn't
being processed correctly.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Bootstrapping hppa64? CPP problem

[Steve Ellcey]

> I filed a PR for the exact same problem on vax-dec-ultrix4.3.  However,
> I couldn't duplicate it with a cross compiler.  It appears '!' isn't
> being processed correctly.

I am trying to dig into this some more and I don't think it is in the
'!'  code.  I am currently looking at eval_token, being called from
_cpp_parse_expr, being called from do_if and am looking at the symbol
_SVID2 in eval_token.

On a system where things work I get into 'case CPP_NAME' inside
eval_token and find that the if statement:

	if (token->val.node == pfile->spec_nodes.n_defined)

is true and we call parse_defined and return the correct value.

On hppa64 I get to the same location in the code and find that this if
statement is false and the two pointers are not the same.  I was
wondering if it was a 64 bit issue with the cpp hash table or something?
Is vax-dec-ultrix4.3 64 bits?  The two values I see being compared
aren't even remotely close on hppa64 and look to be in different sections.

(gdb) p token->val.node
$1 = (struct cpp_hashnode *) 0x5f696e5f6e756c6c
(gdb) p pfile->spec_nodes.n_defined
$2 = (struct cpp_hashnode *) 0x80000001000c6030

pfile->spec_nodes.n_defined looks like a basic 64 bit data pointer on
hppa64 but token->val.node looks weird like it might be in text or
read-only memory somewhere.

Steve Ellcey
sje@cup.hp.com

Re: Bootstrapping hppa64? CPP problem

[Jeff Law]

 In message <200207110002.RAA03057@hpsje.cup.hp.com>, Steve Ellcey writes:
 >(gdb) p token->val.node
 >$1 = (struct cpp_hashnode *) 0x5f696e5f6e756c6c
 >(gdb) p pfile->spec_nodes.n_defined
 >$2 = (struct cpp_hashnode *) 0x80000001000c6030
If you translate topen->val.node into ascii you get:

_in_null

Which certainly looks suspicious -- it's certainly 0x5f... certainly
isn't a valid PA64 pointer.  I'd suspect memory corruption somewhere.

jeff

Re: Bootstrapping hppa64? CPP problem

[Neil Booth]

Steve Ellcey wrote:-

> On hppa64 I get to the same location in the code and find that this if
> statement is false and the two pointers are not the same.  I was
> wondering if it was a 64 bit issue with the cpp hash table or something?
> Is vax-dec-ultrix4.3 64 bits?  The two values I see being compared
> aren't even remotely close on hppa64 and look to be in different sections.
> 
> (gdb) p token->val.node
> $1 = (struct cpp_hashnode *) 0x5f696e5f6e756c6c
> (gdb) p pfile->spec_nodes.n_defined
> $2 = (struct cpp_hashnode *) 0x80000001000c6030
> 
> pfile->spec_nodes.n_defined looks like a basic 64 bit data pointer on
> hppa64 but token->val.node looks weird like it might be in text or
> read-only memory somewhere.

Hmm.  It looks like ASCII text "_ie_null".  Dunno what to say
really 8-)

What's the alignment of double on your target?  And what's
the strictest alignment?

Neil.

Re: Bootstrapping hppa64? CPP problem

[John David Anglin]

> What's the alignment of double on your target?  And what's
> the strictest alignment?

64 and 1, respectively.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Bootstrapping hppa64? CPP problem

[John David Anglin]

> > I am curious if anyone is currently bootstrapping the hppa64 GCC
> > compiler from the latest sources?  I am running into a very curious cpp
> > problem.  With the attached example, using the cc1 that I just built I
> > get two definitions of sigpause showing up because _SVID2 seems to be
> > considered defined and undefined at the same time.  It doesn't happen on
> > the other platforms I have tried but it happens consistenly for me on
> > PA64.

I am currently bootstrapping the latest sources for 3.1.1 and 3.2.
3.2 is now in stage2 and doesn't exhibit the problem described, so I
expect that you have a problem with your tools.

There have been a fair number of changes to binutils affecting hppa64
in the last month or so.  I suggest you rebuild them.  The only unexpected
errors should be 7 in the ld suite.  Then, I suggest that you build
3.1.1 starting with either the HP builtin or ANSI compiler.  You should
be able to build 3.2 starting with the HP ANSI compiler.  I'm using
3.1.1 as my default for hppa64 builds.

I will let you know if the problem that you describe appears later
in the build process.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Bootstrapping hppa64? CPP problem

[Steve Ellcey]

Hm, curiouser and curiouser.

Walking through with the debugger, I stop in _cpp_parse_expr at line 739
just before calling eval_token.  I print 'token->val.node' and I see
0x80000001000c6030.  I then step into eval_token and token->val.node is
0x5f696e5f6e756c6c.

In fact if I print out token before the call to eval_token, I see:

(gdb) p *token
$1 = {line = 19, col = 6, type = CPP_NAME, flags = 0 '\000', val = {
    node = 0x80000001000c6030, source = 0x80000001000c6030, str = {
      len = 2147483649, text = 0x0}, arg_no = 2147483649, c = 128 '\200'}}

After the call I see:

(gdb) p *token
$2 = {line = 1734702175, col = 24948, type = 116, flags = 114 'r', val = {
    node = 0x5f696e5f6e756c6c, source = 0x5f696e5f6e756c6c, str = {
      len = 1600745055,
      text = 0x69666965645f6272 <Error reading address 0x69666965645f6272: Bad a
ddress>}, arg_no = 1600745055, c = 95 '_'}}

Which looks like complete junk.  So the argument token is not being
passed correctly to eval_token.  The first argument (pfile) looks OK
after getting into eval_token, it has the address 0x800000010007b450
before and after the call but token gets changed from 0x800000010007b8d8
before the call to 0x40000000000633e0 inside eval_token which is wrong.

I just rebuilt gcc with the HP compiler instead of using a 3.0.2 based
GCC which I had been using and that seems to be behaving correctly so I
think the basic problem here is a bug in my hppa64 GCC (3.0.2) that I am
using to build the latest GCC with.  I am going to rebuild the latest
sources using HP C and then use that to bootstrap GCC and see if that
works better.

Steve Ellcey
sje@cup.hp.com

Re: Bootstrapping hppa64? CPP problem

[John David Anglin]

> After the call I see:
> 
> (gdb) p *token
> $2 = {line = 1734702175, col = 24948, type = 116, flags = 114 'r', val = {
>     node = 0x5f696e5f6e756c6c, source = 0x5f696e5f6e756c6c, str = {
>       len = 1600745055,
>       text = 0x69666965645f6272 <Error reading address 0x69666965645f6272: Bad a
> ddress>}, arg_no = 1600745055, c = 95 '_'}}
> 
> Which looks like complete junk.  So the argument token is not being

You have to be really careful with gdb as it's not very smart about when
variables are valid or loaded from arguments.  I suspect that 'p *(CAST)$r26
would correctly print the struct.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)