GCC 4.3 and PLABEL32 issues.

GCC 4.3 and PLABEL32 issues.

[Carlos O'Donell]

Dave,

The following reduced testcase:

cat >> foo.c <<EOF
#include <stdio.h>
#include <stdlib.h>

int main (void) {
  printf ("&printf = %x\n", (unsigned long)&printf);
  if (((unsigned long) &printf) & 3)
    {
      printf ("printf is a PLABEL32\n");
    }
  return 0;
}
EOF

carlos@firin:~/fsrc/gcc-work$
/usr/local/tools/bin/hppa-linux-gcc-4.2.4 -o foo foo.c
carlos@firin:~/fsrc/gcc-work$ ./foo
&printf = 119ea
printf is a PLABEL32

carlos@firin:~/fsrc/gcc-work$
/usr/local/tools/bin/hppa-linux-gcc-4.3.1 -o foo foo.c
carlos@firin:~/fsrc/gcc-work$ ./foo
&printf = 119ea

GCC 4.3, even at -O0, reduces "((unsigned long) &printf) & 3)" to "0".

~~~ foo.c.003t.original ~~~
;; Function main (main)
;; enabled by -tree-original

{
  printf ((const char * restrict) (char *) "&printf = %x\n", (long
unsigned int) printf);
  if (0)
    {
      printf ((const char * restrict) (char *) "printf is a PLABEL32\n");
    }
  return 0;
}
~~~
If the if condition is reduced to "0" as early as 003t.original, does
that mean it's the C frontend fault?

This issue is breaks glibc's detection of PLABEL's during startup
relocation processing.

Cheers,
Carlos.

Re: GCC 4.3 and PLABEL32 issues.

[John David Anglin]

> If the if condition is reduced to "0" as early as 003t.original, does
> that mean it's the C frontend fault?

Yes.  If I remember correctly, casting a pointer to an integer type
is implementation defined.

> This issue is breaks glibc's detection of PLABEL's during startup
> relocation processing.

This definitely needs a PR.  It should be marked as a regression.
This probably also breaks the unwind code in libjava as it has a
similar check.  There's also __canonicalize_funcptr_for_compare.

It's something of a puzzle as to why this didn't appear in testing.
It suggests we aren't testing the build libraries but installed libraries.

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

Re: GCC 4.3 and PLABEL32 issues.

[Carlos O'Donell]

On Tue, Mar 25, 2008 at 11:20 PM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
> > If the if condition is reduced to "0" as early as 003t.original, does
>  > that mean it's the C frontend fault?
>
>  Yes.  If I remember correctly, casting a pointer to an integer type
>  is implementation defined.

I mention this in the PR.

>  > This issue is breaks glibc's detection of PLABEL's during startup
>  > relocation processing.
>
>  This definitely needs a PR.  It should be marked as a regression.
>  This probably also breaks the unwind code in libjava as it has a
>  similar check.  There's also __canonicalize_funcptr_for_compare.
>
>  It's something of a puzzle as to why this didn't appear in testing.
>  It suggests we aren't testing the build libraries but installed libraries.

PR/35705 filed, and CC'd to you.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705

Cheers,
Carlos.

Re: GCC 4.3 and PLABEL32 issues.

[Matthew Wilcox]

On Tue, Mar 25, 2008 at 11:20:00PM -0400, John David Anglin wrote:
> This definitely needs a PR.  It should be marked as a regression.
> This probably also breaks the unwind code in libjava as it has a
> similar check.  There's also __canonicalize_funcptr_for_compare.
> 
> It's something of a puzzle as to why this didn't appear in testing.
> It suggests we aren't testing the build libraries but installed libraries.

I thought Mozilla also used the low bits of pointers for special cases
... and the kernel even has macros to return 'either a pointer or an
error code' (PTR_ERR, ERR_PTR, IS_ERR).  Although the kernel probably
wouldn't trip this, as I can't think of any function which returns a
function-pointer-or-error (and besides the test isn't 'are the bottom
bits set', but 'if you cast this pointer back to an unsigned long, is it
greater than -4095'.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: GCC 4.3 and PLABEL32 issues.

[John David Anglin]

> I thought Mozilla also used the low bits of pointers for special cases

Effectively, all code that has to deal with the underlying details
of the function pointer implementation is affected.  This includes
unwind code, and code to dynamically load libraries and plugins.

> ... and the kernel even has macros to return 'either a pointer or an
> error code' (PTR_ERR, ERR_PTR, IS_ERR).  Although the kernel probably
> wouldn't trip this, as I can't think of any function which returns a
> function-pointer-or-error (and besides the test isn't 'are the bottom
> bits set', but 'if you cast this pointer back to an unsigned long, is it
> greater than -4095'.

The PLABEL bit is defined in the runtime and only affects the runtime.
I think the only time the kernel would need to care about this is for
signal handlers.  In the runtime, page 0 is reserved to catch invalid
pointer accesses.  I'm sure the kernel has to be aware of this.

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