[parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Randolph Chung]

In reference to a message from Matthias Klose, dated Mar 01:
> Matthias Klose writes:
> > AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
> > code due to the changed exception handling (now DWARF2 based). As
> > libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?
> > Currently 3.2 is in unstable only. Would you want to start the
> > recompilation before 3.2 based binaries go to testing?
> > 
> > The packaging for 3.3 can be found in the Debian CVS.
> 
> You can get test packages from
> 	http://ftp-master.debian.org/~doko/gcc-3.3/

well.... this is not looking good. after installing these in a freshly
built sarge chroot, all c++ programs stop working (well, i've only tried
two -- apt and fakeroot)

(btw, small packaging detail, but the libstdc++*-dev package above
cannot be installed cleanly because it overwrites things in the current
3.2 package)

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

[parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Randolph Chung]

In reference to a message from Matthias Klose, dated Mar 01:
> Matthias Klose writes:
> > AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
> > code due to the changed exception handling (now DWARF2 based). As
> > libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?
> > Currently 3.2 is in unstable only. Would you want to start the
> > recompilation before 3.2 based binaries go to testing?
> > 
> > The packaging for 3.3 can be found in the Debian CVS.
> 
> You can get test packages from
> 	http://ftp-master.debian.org/~doko/gcc-3.3/

well.... this is not looking good. after installing these in a freshly
built sarge chroot, all c++ programs stop working (well, i've only tried
two -- apt and fakeroot)

(btw, small packaging detail, but the libstdc++*-dev package above
cannot be installed cleanly because it overwrites things in the current
3.2 package)

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> In reference to a message from Matthias Klose, dated Mar 01:
> > Matthias Klose writes:
> > > AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
> > > code due to the changed exception handling (now DWARF2 based). As
> > > libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?

Possibly, this issue should be broached with the libstdc++ maintainers.
In my testing, I have moved to installing each gcc version in its own
directory.

I should note again that 3.3 has a ABI change in the passing of small
structures.  It also contains a fix for function pointer comparison.
As glibc does function comparison in a number of routines, it needs
recompilation with 3.3 to work correctly.  Then, I believe gcc needs
to be rebuilt as libstdc++ depends on the thread implementation.  The
last glibc linuxthread code that I downloaded was still broken.  I know
Carlos has a patch in the works.

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

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> In reference to a message from Matthias Klose, dated Mar 01:
> > Matthias Klose writes:
> > > AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
> > > code due to the changed exception handling (now DWARF2 based). As
> > > libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?

Possibly, this issue should be broached with the libstdc++ maintainers.
In my testing, I have moved to installing each gcc version in its own
directory.

I should note again that 3.3 has a ABI change in the passing of small
structures.  It also contains a fix for function pointer comparison.
As glibc does function comparison in a number of routines, it needs
recompilation with 3.3 to work correctly.  Then, I believe gcc needs
to be rebuilt as libstdc++ depends on the thread implementation.  The
last glibc linuxthread code that I downloaded was still broken.  I know
Carlos has a patch in the works.

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

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[M. Grabert]

On Sun, 2 Mar 2003, John David Anglin wrote:

> I should note again that 3.3 has a ABI change in the passing of small
> structures.  It also contains a fix for function pointer comparison.
> As glibc does function comparison in a number of routines, it needs
> recompilation with 3.3 to work correctly.  Then, I believe gcc needs
> to be rebuilt as libstdc++ depends on the thread implementation.  The
> last glibc linuxthread code that I downloaded was still broken.  I know
> Carlos has a patch in the works.

This means that future glibc (in Debian/PA-RISC, unstable) will/must
be compiled with gcc-3.3, along with all C++-programmes. Is this going to
happen soon or do you wait until gcc-3.3 is offically released?

Does this also imply that gcc/g++-3.3 will be the new default compiler
for unstable then? What (kind of) existing broken applications will be
fixed by recompiling with gcc-3.3?


Just curious, Max

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[M. Grabert]

On Sun, 2 Mar 2003, John David Anglin wrote:

> I should note again that 3.3 has a ABI change in the passing of small
> structures.  It also contains a fix for function pointer comparison.
> As glibc does function comparison in a number of routines, it needs
> recompilation with 3.3 to work correctly.  Then, I believe gcc needs
> to be rebuilt as libstdc++ depends on the thread implementation.  The
> last glibc linuxthread code that I downloaded was still broken.  I know
> Carlos has a patch in the works.

This means that future glibc (in Debian/PA-RISC, unstable) will/must
be compiled with gcc-3.3, along with all C++-programmes. Is this going to
happen soon or do you wait until gcc-3.3 is offically released?

Does this also imply that gcc/g++-3.3 will be the new default compiler
for unstable then? What (kind of) existing broken applications will be
fixed by recompiling with gcc-3.3?


Just curious, Max

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Randolph Chung]

> This means that future glibc (in Debian/PA-RISC, unstable) will/must
> be compiled with gcc-3.3, along with all C++-programmes. Is this going to
> happen soon or do you wait until gcc-3.3 is offically released?

this is more or less up to the Debian release manager, but we are
probably not going to start gcc-3.3 transition until the gcc-3.2
transition is over.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Randolph Chung]

> This means that future glibc (in Debian/PA-RISC, unstable) will/must
> be compiled with gcc-3.3, along with all C++-programmes. Is this going to
> happen soon or do you wait until gcc-3.3 is offically released?

this is more or less up to the Debian release manager, but we are
probably not going to start gcc-3.3 transition until the gcc-3.2
transition is over.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> Does this also imply that gcc/g++-3.3 will be the new default compiler
> for unstable then? What (kind of) existing broken applications will be
> fixed by recompiling with gcc-3.3?

I can't be very specific as to what's fixed as most of the fixes have
come about from fixing failures in the GCC and binutils testsuites.

The passing of small structs by value mainly affects C++ code.  It's
rather uncommon to pass structs by value in C.  I'm not aware of any
impact on glibc or hpux libc, for example.

The comparison of function pointers in dynamic applications was
broken.  This was found in the binutils testsuite.  It potentially
affects signal handlers, running of initializers and finalizers, etc.
The PA has a rather unique way of handling function pointers.  A function
pointer points to a function descriptor when the plabel bit is set,
otherwise it points directly to the entry point of the function.
The dynamic loader does the initial setup of the function descriptors.
The first call to any function actually transfers to the routine
fixup in the dynamic loader.  It resolves the address of the function
to call.  Function pointer comparison also requires that the function
address be resolved.  In GCC 3.0.4, we just compared the function
descriptor pointers.  However, there can be multiple function decriptors
pointing to the same function.  So, this wasn't reliable.  When the
dynamic loader design was done a couple of years ago, this appears
to have been overlooked.  HP-UX 11 has what they call official procedure
descriptors which are unique.  Because it's not that common to pass
function pointers around from one dynamic object to another and compare
them with pointers from another object, the problem doesn't arise that
frequently.

The dwarf2 EH implementation was done mainly for compatibility with
other linux ports.  It's probably more efficient the using sjlj
exceptions.  Potentially, it's something that ada can use.  I believe
that ACT is using dwarf2 EH in their commercial ada distribution
under hpux.  It may also be useful for gdb.  However, I don't think
there is a difference in GCC testresults.

The pthread design in glibc also is potentially an ABI breaker.

These are the PA specific ABI issues that I recall, but there might
be more.

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

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> Does this also imply that gcc/g++-3.3 will be the new default compiler
> for unstable then? What (kind of) existing broken applications will be
> fixed by recompiling with gcc-3.3?

I can't be very specific as to what's fixed as most of the fixes have
come about from fixing failures in the GCC and binutils testsuites.

The passing of small structs by value mainly affects C++ code.  It's
rather uncommon to pass structs by value in C.  I'm not aware of any
impact on glibc or hpux libc, for example.

The comparison of function pointers in dynamic applications was
broken.  This was found in the binutils testsuite.  It potentially
affects signal handlers, running of initializers and finalizers, etc.
The PA has a rather unique way of handling function pointers.  A function
pointer points to a function descriptor when the plabel bit is set,
otherwise it points directly to the entry point of the function.
The dynamic loader does the initial setup of the function descriptors.
The first call to any function actually transfers to the routine
fixup in the dynamic loader.  It resolves the address of the function
to call.  Function pointer comparison also requires that the function
address be resolved.  In GCC 3.0.4, we just compared the function
descriptor pointers.  However, there can be multiple function decriptors
pointing to the same function.  So, this wasn't reliable.  When the
dynamic loader design was done a couple of years ago, this appears
to have been overlooked.  HP-UX 11 has what they call official procedure
descriptors which are unique.  Because it's not that common to pass
function pointers around from one dynamic object to another and compare
them with pointers from another object, the problem doesn't arise that
frequently.

The dwarf2 EH implementation was done mainly for compatibility with
other linux ports.  It's probably more efficient the using sjlj
exceptions.  Potentially, it's something that ada can use.  I believe
that ACT is using dwarf2 EH in their commercial ada distribution
under hpux.  It may also be useful for gdb.  However, I don't think
there is a difference in GCC testresults.

The pthread design in glibc also is potentially an ABI breaker.

These are the PA specific ABI issues that I recall, but there might
be more.

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

RE: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

>-- Original Message --
>From: Randolph Chung <tausq@debian.org>
>To: Matthias Klose <doko@cs.tu-berlin.de>
>Cc: debian-hppa@lists.debian.org, debian-gcc@lists.debian.org,
>	parisc-linux@lists.parisc-linux.org
>Reply-To: Randolph Chung <tausq@debian.org>
>Subject: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa
>Date: Sat, 1 Mar 2003 20:59:36 -0800
>
>
>In reference to a message from Matthias Klose, dated Mar 01:
>> Matthias Klose writes:
>> > AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
>> > code due to the changed exception handling (now DWARF2 based). As
>> > libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?
>> > Currently 3.2 is in unstable only. Would you want to start the
>> > recompilation before 3.2 based binaries go to testing?
>> > 
>> > The packaging for 3.3 can be found in the Debian CVS.

hmm is there an url explaining how to grab it?

>> 
>> You can get test packages from
>> 	http://ftp-master.debian.org/~doko/gcc-3.3/
>

Nice and is it also possible to produce a 64bits version of gcc?

>well.... this is not looking good. after installing these in a freshly
>built sarge chroot, all c++ programs stop working (well, i've only tried
>two -- apt and fakeroot)
>
>(btw, small packaging detail, but the libstdc++*-dev package above
>cannot be installed cleanly because it overwrites things in the current
>3.2 package)
>
>randolph
>-- 
>Randolph Chung
>Debian GNU/Linux Developer, hppa/ia64 ports
>http://www.tausq.org/
>_______________________________________________
>parisc-linux mailing list
>parisc-linux@lists.parisc-linux.org
>http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Thanks,
    Joel

---------------------------------
Vous surfez avec une ligne classique ?
Faites des economies avec Tiscali Complete
... Plus d'info sur http://complete.tiscali.be

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> Nice and is it also possible to produce a 64bits version of gcc?

Last time I tried (couple of weeks ago), it was possible to build
a 64-bit cross starting with 3.3.  This still doesn't work with 3.2.

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

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Randolph Chung]

[Note: trimmed cc list]

> Last time I tried (couple of weeks ago), it was possible to build
> a 64-bit cross starting with 3.3.  This still doesn't work with 3.2.

also 64-bit hppa64-linux gcc-3.2 (built with 3.3) ICEs regularly. For
people using this to build kernels, I would suggest staying with 3.0.4
for now.

(I'm also seeing reproducible crashes when running hppa64-linux-ld now,
still need to track that down)

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

Randolph Chung wrote:

>[Note: trimmed cc list]
>
>  
>
>>Last time I tried (couple of weeks ago), it was possible to build
>>a 64-bit cross starting with 3.3.  This still doesn't work with 3.2.
>>    
>>
>
>also 64-bit hppa64-linux gcc-3.2 (built with 3.3) ICEs regularly. For
>people using this to build kernels, I would suggest staying with 3.0.4
>for now.
>
>(I'm also seeing reproducible crashes when running hppa64-linux-ld now,
>still need to track that down)
>
>randolph
>  
>
Ok Randolph, I will wait so because the question was in fact to rebuild 
a kernel 64bits with smp support (up works fine) but smp seems to 
failled just after init the first cpu and would like to see what is the 
problem.

Thanks for advise,  
    Joel

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> Nice and is it also possible to produce a 64bits version of gcc?

Last time I tried (couple of weeks ago), it was possible to build
a 64-bit cross starting with 3.3.  This still doesn't work with 3.2.

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

RE: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

>-- Original Message --
>From: Randolph Chung <tausq@debian.org>
>To: Matthias Klose <doko@cs.tu-berlin.de>
>Cc: debian-hppa@lists.debian.org, debian-gcc@lists.debian.org,
>	parisc-linux@lists.parisc-linux.org
>Reply-To: Randolph Chung <tausq@debian.org>
>Subject: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa
>Date: Sat, 1 Mar 2003 20:59:36 -0800
>
>
>In reference to a message from Matthias Klose, dated Mar 01:
>> Matthias Klose writes:
>> > AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
>> > code due to the changed exception handling (now DWARF2 based). As
>> > libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?
>> > Currently 3.2 is in unstable only. Would you want to start the
>> > recompilation before 3.2 based binaries go to testing?
>> > 
>> > The packaging for 3.3 can be found in the Debian CVS.

hmm is there an url explaining how to grab it?

>> 
>> You can get test packages from
>> 	http://ftp-master.debian.org/~doko/gcc-3.3/
>

Nice and is it also possible to produce a 64bits version of gcc?

>well.... this is not looking good. after installing these in a freshly
>built sarge chroot, all c++ programs stop working (well, i've only tried
>two -- apt and fakeroot)
>
>(btw, small packaging detail, but the libstdc++*-dev package above
>cannot be installed cleanly because it overwrites things in the current
>3.2 package)
>
>randolph
>-- 
>Randolph Chung
>Debian GNU/Linux Developer, hppa/ia64 ports
>http://www.tausq.org/
>_______________________________________________
>parisc-linux mailing list
>parisc-linux@lists.parisc-linux.org
>http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Thanks,
    Joel

---------------------------------
Vous surfez avec une ligne classique ?
Faites des economies avec Tiscali Complete
... Plus d'info sur http://complete.tiscali.be

[parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Matthias Klose]

Randolph Chung writes:
> In reference to a message from Matthias Klose, dated Mar 01:
> > Matthias Klose writes:
> > > AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
> > > code due to the changed exception handling (now DWARF2 based). As
> > > libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?
> > > Currently 3.2 is in unstable only. Would you want to start the
> > > recompilation before 3.2 based binaries go to testing?
> > > 
> > > The packaging for 3.3 can be found in the Debian CVS.
> > 
> > You can get test packages from
> > 	http://ftp-master.debian.org/~doko/gcc-3.3/
> 
> well.... this is not looking good. after installing these in a freshly
> built sarge chroot, all c++ programs stop working (well, i've only tried
> two -- apt and fakeroot)

You can find updated packages at
	http://ftp-master.debian.org/~doko/gcc-3.3/hppa/
checked building bash (fakeroot) and upgrading an unstable chroot (apt).

> (btw, small packaging detail, but the libstdc++*-dev package above
> cannot be installed cleanly because it overwrites things in the current
> 3.2 package)

There is still one conflict for libstdc++5-dev (<= 1:3.2.3-0pre3), so
please install libstdc++5-dev (1:3.2.3-0pre4) first.

	Matthias

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> Randolph Chung writes:
> > In reference to a message from Matthias Klose, dated Mar 01:
> > > Matthias Klose writes:
> > > > AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
> > > > code due to the changed exception handling (now DWARF2 based). As
> > > > libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?
> > > > Currently 3.2 is in unstable only. Would you want to start the
> > > > recompilation before 3.2 based binaries go to testing?
> > > > 
> > > > The packaging for 3.3 can be found in the Debian CVS.
> > > 
> > > You can get test packages from
> > > 	http://ftp-master.debian.org/~doko/gcc-3.3/
> > 
> > well.... this is not looking good. after installing these in a freshly
> > built sarge chroot, all c++ programs stop working (well, i've only tried
> > two -- apt and fakeroot)
> 
> You can find updated packages at
> 	http://ftp-master.debian.org/~doko/gcc-3.3/hppa/
> checked building bash (fakeroot) and upgrading an unstable chroot (apt).
> 
> > (btw, small packaging detail, but the libstdc++*-dev package above
> > cannot be installed cleanly because it overwrites things in the current
> > 3.2 package)
> 
> There is still one conflict for libstdc++5-dev (<= 1:3.2.3-0pre3), so
> please install libstdc++5-dev (1:3.2.3-0pre4) first.

Did you configure 3.3 using "--enable-sjlj-exceptions=yes"?  That way
the 3.3 C++ library should be compatible with the previous 3.3 library.
The switch to dwarf2 can be delayed until the next debian release.

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

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Randolph Chung]

> Did you configure 3.3 using "--enable-sjlj-exceptions=yes"?  That way
> the 3.3 C++ library should be compatible with the previous 3.3 library.
> The switch to dwarf2 can be delayed until the next debian release.

yeah, i exchanged some mail with Matthias about this.

Anyway, I have the debs installed in a chroot now. Will start building
random stuff and see what happens :)

stay tuned,
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Randolph Chung]

> Did you configure 3.3 using "--enable-sjlj-exceptions=yes"?  That way
> the 3.3 C++ library should be compatible with the previous 3.3 library.
> The switch to dwarf2 can be delayed until the next debian release.

yeah, i exchanged some mail with Matthias about this.

Anyway, I have the debs installed in a chroot now. Will start building
random stuff and see what happens :)

stay tuned,
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> Randolph Chung writes:
> > In reference to a message from Matthias Klose, dated Mar 01:
> > > Matthias Klose writes:
> > > > AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
> > > > code due to the changed exception handling (now DWARF2 based). As
> > > > libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?
> > > > Currently 3.2 is in unstable only. Would you want to start the
> > > > recompilation before 3.2 based binaries go to testing?
> > > > 
> > > > The packaging for 3.3 can be found in the Debian CVS.
> > > 
> > > You can get test packages from
> > > 	http://ftp-master.debian.org/~doko/gcc-3.3/
> > 
> > well.... this is not looking good. after installing these in a freshly
> > built sarge chroot, all c++ programs stop working (well, i've only tried
> > two -- apt and fakeroot)
> 
> You can find updated packages at
> 	http://ftp-master.debian.org/~doko/gcc-3.3/hppa/
> checked building bash (fakeroot) and upgrading an unstable chroot (apt).
> 
> > (btw, small packaging detail, but the libstdc++*-dev package above
> > cannot be installed cleanly because it overwrites things in the current
> > 3.2 package)
> 
> There is still one conflict for libstdc++5-dev (<= 1:3.2.3-0pre3), so
> please install libstdc++5-dev (1:3.2.3-0pre4) first.

Did you configure 3.3 using "--enable-sjlj-exceptions=yes"?  That way
the 3.3 C++ library should be compatible with the previous 3.3 library.
The switch to dwarf2 can be delayed until the next debian release.

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

[parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Matthias Klose]

Randolph Chung writes:
> In reference to a message from Matthias Klose, dated Mar 01:
> > Matthias Klose writes:
> > > AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
> > > code due to the changed exception handling (now DWARF2 based). As
> > > libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?
> > > Currently 3.2 is in unstable only. Would you want to start the
> > > recompilation before 3.2 based binaries go to testing?
> > > 
> > > The packaging for 3.3 can be found in the Debian CVS.
> > 
> > You can get test packages from
> > 	http://ftp-master.debian.org/~doko/gcc-3.3/
> 
> well.... this is not looking good. after installing these in a freshly
> built sarge chroot, all c++ programs stop working (well, i've only tried
> two -- apt and fakeroot)

You can find updated packages at
	http://ftp-master.debian.org/~doko/gcc-3.3/hppa/
checked building bash (fakeroot) and upgrading an unstable chroot (apt).

> (btw, small packaging detail, but the libstdc++*-dev package above
> cannot be installed cleanly because it overwrites things in the current
> 3.2 package)

There is still one conflict for libstdc++5-dev (<= 1:3.2.3-0pre3), so
please install libstdc++5-dev (1:3.2.3-0pre4) first.

	Matthias

RE: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

Hi Randolph,

>-- Original Message --
>From: Randolph Chung <tausq@debian.org>
>To: Matthias Klose <doko@cs.tu-berlin.de>
>Cc: debian-hppa@lists.debian.org, debian-gcc@lists.debian.org,
>	parisc-linux@lists.parisc-linux.org
>Reply-To: Randolph Chung <tausq@debian.org>
>Subject: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa
>Date: Sat, 1 Mar 2003 20:59:36 -0800
>
>
>In reference to a message from Matthias Klose, dated Mar 01:
>> Matthias Klose writes:
>> > AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
>> > code due to the changed exception handling (now DWARF2 based). As
>> > libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?
>> > Currently 3.2 is in unstable only. Would you want to start the
>> > recompilation before 3.2 based binaries go to testing?
>> > 
>> > The packaging for 3.3 can be found in the Debian CVS.
>> 
>> You can get test packages from
>> 	http://ftp-master.debian.org/~doko/gcc-3.3/
>
>well.... this is not looking good. after installing these in a freshly
>built sarge chroot, all c++ programs stop working (well, i've only tried
>two -- apt and fakeroot)
>
>(btw, small packaging detail, but the libstdc++*-dev package above
>cannot be installed cleanly because it overwrites things in the current
>3.2 package)
>

Sorry in advance if I am annoying.

I am looking to rebuild gcc-3.3 64bits to rebuild the last kernel 2.4 to
conitnue my investigation about smp(64bits) [which failled to boot on a N4000
when compile d with gcc-3.2 get from unofficial-debs].

To do I download the very last src from Matthias Klose who advise me to my
question:
>> Do you have some idea how to rebuild it from dpkg sources?
>> (I would like avoid the toolchain procedure if possible)

>look at debian/rules.defs for the support to build a cross compiler.
>It was submitted some weeks ago. I didn't check this myself yet.

I have a look but it is not clear to me; can you help me in more details?
(ps: I already install the last Matthias gcc-3.3 dpkg 32bits;
according to your <http://lists.parisc-linux.org/pipermail/parisc-linux/2003-February/019170.html>
it is a prerequisite)

Thanks in advance,
    Joel


---------------------------------
Vous surfez avec une ligne classique ?
Faites des economies avec Tiscali Complete
... Plus d'info sur http://complete.tiscali.be

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Randolph Chung]

> I am looking to rebuild gcc-3.3 64bits to rebuild the last kernel 2.4 to
> conitnue my investigation about smp(64bits) [which failled to boot on a N4000
> when compile d with gcc-3.2 get from unofficial-debs].

If you are working on 64-bit, I would advise staying with 3.0.4 for
now.... no one has tested 3.3 hppa64-linux-gcc at all, so it will just
be introducing more unknowns into the problem.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Randolph Chung]

> I am looking to rebuild gcc-3.3 64bits to rebuild the last kernel 2.4 to
> conitnue my investigation about smp(64bits) [which failled to boot on a N4000
> when compile d with gcc-3.2 get from unofficial-debs].

If you are working on 64-bit, I would advise staying with 3.0.4 for
now.... no one has tested 3.3 hppa64-linux-gcc at all, so it will just
be introducing more unknowns into the problem.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

>-- Original Message --
>Date: Wed, 12 Mar 2003 09:35:05 -0800
>From: Randolph Chung <tausq@debian.org>
>To: Joel Soete <jsoe0708@tiscali.be>
>Cc: Matthias Klose <doko@cs.tu-berlin.de>,
>	debian-hppa@lists.debian.org, debian-gcc@lists.debian.org,
>	parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa
>Reply-To: Randolph Chung <tausq@debian.org>
>
>
>> I am looking to rebuild gcc-3.3 64bits to rebuild the last kernel 2.4
to
>> conitnue my investigation about smp(64bits) [which failled to boot on
a
>N4000
>> when compile d with gcc-3.2 get from unofficial-debs].
>
>If you are working on 64-bit, I would advise staying with 3.0.4 for
>now.... no one has tested 3.3 hppa64-linux-gcc at all, so it will just
>be introducing more unknowns into the problem.
>
Ok I am gonna try to rebuild it with gcc-3.0.

Thanks for advise,
    Joel

---------------------------------
Vous surfez avec une ligne classique ?
Faites des economies avec Tiscali Complete
... Plus d'info sur http://complete.tiscali.be

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

>>
>Ok I am gonna try to rebuild it with gcc-3.0.
>

Wel I just do it (in 32bits naturaly) and already encounter a problem :_)
:
`gcc -print-libgcc-file-name` /usr/src/work/linux-2.4.20-pa28/arch/parisc/lib/lib.a
/usr/src/work/linux-2.4.20-pa28/lib/lib.a  \
        --end-group \
        -o vmlinux
net/network.o(.text.rtnetlink_rcv+0x84): In function `rtnetlink_rcv':
: undefined reference to `rtnetlink_rcv_skb'
make: *** [vmlinux] Error 1

(with gcc-3.2 with same src && same .config there was no pb)

Thanks in advance for advise,
    Joel



---------------------------------
Vous surfez avec une ligne classique ?
Faites des economies avec Tiscali Complete
... Plus d'info sur http://complete.tiscali.be

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

>>
>Ok I am gonna try to rebuild it with gcc-3.0.
>

Wel I just do it (in 32bits naturaly) and already encounter a problem :_)
:
`gcc -print-libgcc-file-name` /usr/src/work/linux-2.4.20-pa28/arch/parisc/lib/lib.a
/usr/src/work/linux-2.4.20-pa28/lib/lib.a  \
        --end-group \
        -o vmlinux
net/network.o(.text.rtnetlink_rcv+0x84): In function `rtnetlink_rcv':
: undefined reference to `rtnetlink_rcv_skb'
make: *** [vmlinux] Error 1

(with gcc-3.2 with same src && same .config there was no pb)

Thanks in advance for advise,
    Joel



---------------------------------
Vous surfez avec une ligne classique ?
Faites des economies avec Tiscali Complete
... Plus d'info sur http://complete.tiscali.be

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Matthew Wilcox]

On Fri, Mar 14, 2003 at 01:48:59PM +0100, Joel Soete wrote:
> net/network.o(.text.rtnetlink_rcv+0x84): In function `rtnetlink_rcv':
> : undefined reference to `rtnetlink_rcv_skb'
> make: *** [vmlinux] Error 1
> 
> (with gcc-3.2 with same src && same .config there was no pb)

You've just hit the gcc thinks it's smarter than you are bug.

net/core/rtnetlink.c:extern __inline__ int rtnetlink_rcv_skb(struct sk_buff *skb)

gcc 3.3 decides to not believe you want this function inlined.  probably
the right fix for this is to make this function static inline (you can
drop the `__' around inline, it's not necessary).  This is also the case
for linux 2.5.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

>
>On Fri, Mar 14, 2003 at 01:48:59PM +0100, Joel Soete wrote:
>> net/network.o(.text.rtnetlink_rcv+0x84): In function `rtnetlink_rcv':
>> : undefined reference to `rtnetlink_rcv_skb'
>> make: *** [vmlinux] Error 1
>> 
>> (with gcc-3.2 with same src && same .config there was no pb)
>
>You've just hit the gcc thinks it's smarter than you are bug.
>
>net/core/rtnetlink.c:extern __inline__ int rtnetlink_rcv_skb(struct sk_buff
>*skb)
>
>gcc 3.3 decides to not believe you want this function inlined.  probably
>the right fix for this is to make this function static inline (you can
>drop the `__' around inline, it's not necessary).  This is also the case
>for linux 2.5.
>
Right Willy that allow to compile :)

Unfortunately it failled to boot :_( with following dump:
Freeing unused kernel memory: 246k freed

Stack Dump:
 10674680:  0006ff0f 10371278 100dc000 00000000 
 10674670:  107dd2a0 101639e4 107dd220 103fcc80 
 10674660:  10398010 1003bd20 00027174 faf00068 
 10674650:  100bbd20 00000001 00000040 100bba00 
 10674640:  00000000 00000000 00000000 00000004 
 10674630:  faf00290 101342f8 00020002 00020002 

Kernel addresses on the stack:
 [<101639e4>]  [<101342f8>]  [<1010bbf8>]  [<101346d4>] 
 [<10110f90>]  [<10110084>]  [<1010fcf4>]  [<10164e10>] 
 [<101639e4>]  [<1017bfc4>]  [<1017c21c>]  [<1012d9f4>] 


Kernel Fault: Code=15 regs=10674680 (Addr=00027750)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001101111111100001111 Not tainted
r00-03  00000000 103eee50 101342f8 00027750
r04-07  00000000 0000000e 0000000e 00027174
r08-11  00016800 00000001 10674000 1017c21c
r12-15  00027174 ffffffff 00000000 00000000
r16-19  103af5c0 00027974 ffffffff 10398010
r20-23  00001000 00027753 fffffff8 100bb9f4
r24-27  00000000 10674558 00027752 10398010
r28-31  00027752 00000000 10674680 40061077
sr0-3   00000001 00000001 00000000 00000001
sr4-7   00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 10351b7c 10351b80
 IIR: 0c601094    ISR: 00000000  IOR: 00027750
 CPU:        0   CR30: 10674000 CR31: 10438000
 ORIG_R28: 00001000

Submitted to dump_analyser.sh, I obtain:

IAOQ = 10351b7c
Func: __canonicalize_funcptr_for_compare, Off: 38, Addr: 0x10351b7c
10351b70:	2a 6b 50 00 	addil 56800,r19,%r1
10351b74:	48 21 0c a8 	ldw 654(r1),r1
10351b78:	d4 60 1c 1e 	depwi 0,31,2,r3
10351b7c:	0c 60 10 94 	ldw 0(sr0,r3),r20

GR0 = 00000000

GR1 = 103eee50
Func: _GLOBAL_OFFSET_TABLE_, Off: 0, Addr: 0x103eee50

GR2 = 101342f8
Func: do_sigaction, Off: a8, Addr: 0x101342f8
101342f0:	e8 50 0b 39 	b,l 10114894 <print_parisc_device+0x3d0>,rp
101342f4:	0c 73 12 99 	stw r19,-4(sr0,r3)
101342f8:	34 1a 00 02 	ldi 1,r26
101342fc:	e8 50 0b 21 	b,l 10114894 <print_parisc_device+0x3d0>,rp

GR3 = 00027750

GR4 = 00000000

GR5 = 0000000e

GR6 = 0000000e

GR7 = 00027174

GR8 = 00016800

GR9 = 00000001

GR10 = 10674000

GR11 = 1017c21c
Func: sys_dup, Off: 28, Addr: 0x1017c21c
1017c210:	34 13 3f ef 	ldi -9,r19
1017c214:	e8 5f 1b ed 	b,l 1017c010 <dupfd>,rp
1017c218:	08 00 02 40 	nop
1017c21c:	08 1c 02 53 	copy ret0,r19

GR12 = 00027174

GR13 = ffffffff

GR14 = 00000000

GR15 = 00000000

GR16 = 103af5c0
Func: init_mm, Off: 0, Addr: 0x103af5c0

GR17 = 00027974

GR18 = ffffffff

GR19 = 10398010
Func: $global$, Off: 0, Addr: 0x10398010

GR20 = 00001000

GR21 = 00027753

GR22 = fffffff8

GR23 = 100bb9f4

GR24 = 00000000

GR25 = 10674558

GR26 = 00027752

GR27 = 10398010
Func: $global$, Off: 0, Addr: 0x10398010

GR28 = 00027752

GR29 = 00000000

GR30 = 10674680

GR31 = 40061077

Kernel symbols on the stack:
[<101639e4>]: Func: dentry_open, Off: f4, Addr: 0x101639e4
[<101342f8>]: Func: do_sigaction, Off: a8, Addr: 0x101342f8
[<1010bbf8>]: Func: handle_interruption, Off: 150, Addr: 0x1010bbf8
[<101346d4>]: Func: sys_rt_sigaction, Off: 84, Addr: 0x101346d4
[<10110f90>]: Func: syscall_exit, Off: 0, Addr: 0x10110f90
[<10110084>]: Func: intr_check_sig, Off: 0, Addr: 0x10110084
[<1010fcf4>]: Func: _switch_to_ret, Off: 0, Addr: 0x1010fcf4
[<10164e10>]: Func: chrdev_open, Off: 64, Addr: 0x10164e10
[<101639e4>]: Func: dentry_open, Off: f4, Addr: 0x101639e4
[<1017bfc4>]: Func: locate_fd, Off: 70, Addr: 0x1017bfc4
[<1017c21c>]: Func: sys_dup, Off: 28, Addr: 0x1017c21c
[<1012d9f4>]: Func: it_real_fn, Off: 0, Addr: 0x1012d9f4

Done.

It doesn't help me more right now (some sleep need :) ).

Thanks,
    Joel


---------------------------------
Vous surfez avec une ligne classique ?
Faites des economies avec Tiscali Complete
... Plus d'info sur http://complete.tiscali.be

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

>
>On Fri, Mar 14, 2003 at 01:48:59PM +0100, Joel Soete wrote:
>> net/network.o(.text.rtnetlink_rcv+0x84): In function `rtnetlink_rcv':
>> : undefined reference to `rtnetlink_rcv_skb'
>> make: *** [vmlinux] Error 1
>> 
>> (with gcc-3.2 with same src && same .config there was no pb)
>
>You've just hit the gcc thinks it's smarter than you are bug.
>
>net/core/rtnetlink.c:extern __inline__ int rtnetlink_rcv_skb(struct sk_buff
>*skb)
>
>gcc 3.3 decides to not believe you want this function inlined.  probably
>the right fix for this is to make this function static inline (you can
>drop the `__' around inline, it's not necessary).  This is also the case
>for linux 2.5.
>
Right Willy that allow to compile :)

Unfortunately it failled to boot :_( with following dump:
Freeing unused kernel memory: 246k freed

Stack Dump:
 10674680:  0006ff0f 10371278 100dc000 00000000 
 10674670:  107dd2a0 101639e4 107dd220 103fcc80 
 10674660:  10398010 1003bd20 00027174 faf00068 
 10674650:  100bbd20 00000001 00000040 100bba00 
 10674640:  00000000 00000000 00000000 00000004 
 10674630:  faf00290 101342f8 00020002 00020002 

Kernel addresses on the stack:
 [<101639e4>]  [<101342f8>]  [<1010bbf8>]  [<101346d4>] 
 [<10110f90>]  [<10110084>]  [<1010fcf4>]  [<10164e10>] 
 [<101639e4>]  [<1017bfc4>]  [<1017c21c>]  [<1012d9f4>] 


Kernel Fault: Code=15 regs=10674680 (Addr=00027750)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001101111111100001111 Not tainted
r00-03  00000000 103eee50 101342f8 00027750
r04-07  00000000 0000000e 0000000e 00027174
r08-11  00016800 00000001 10674000 1017c21c
r12-15  00027174 ffffffff 00000000 00000000
r16-19  103af5c0 00027974 ffffffff 10398010
r20-23  00001000 00027753 fffffff8 100bb9f4
r24-27  00000000 10674558 00027752 10398010
r28-31  00027752 00000000 10674680 40061077
sr0-3   00000001 00000001 00000000 00000001
sr4-7   00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 10351b7c 10351b80
 IIR: 0c601094    ISR: 00000000  IOR: 00027750
 CPU:        0   CR30: 10674000 CR31: 10438000
 ORIG_R28: 00001000

Submitted to dump_analyser.sh, I obtain:

IAOQ = 10351b7c
Func: __canonicalize_funcptr_for_compare, Off: 38, Addr: 0x10351b7c
10351b70:	2a 6b 50 00 	addil 56800,r19,%r1
10351b74:	48 21 0c a8 	ldw 654(r1),r1
10351b78:	d4 60 1c 1e 	depwi 0,31,2,r3
10351b7c:	0c 60 10 94 	ldw 0(sr0,r3),r20

GR0 = 00000000

GR1 = 103eee50
Func: _GLOBAL_OFFSET_TABLE_, Off: 0, Addr: 0x103eee50

GR2 = 101342f8
Func: do_sigaction, Off: a8, Addr: 0x101342f8
101342f0:	e8 50 0b 39 	b,l 10114894 <print_parisc_device+0x3d0>,rp
101342f4:	0c 73 12 99 	stw r19,-4(sr0,r3)
101342f8:	34 1a 00 02 	ldi 1,r26
101342fc:	e8 50 0b 21 	b,l 10114894 <print_parisc_device+0x3d0>,rp

GR3 = 00027750

GR4 = 00000000

GR5 = 0000000e

GR6 = 0000000e

GR7 = 00027174

GR8 = 00016800

GR9 = 00000001

GR10 = 10674000

GR11 = 1017c21c
Func: sys_dup, Off: 28, Addr: 0x1017c21c
1017c210:	34 13 3f ef 	ldi -9,r19
1017c214:	e8 5f 1b ed 	b,l 1017c010 <dupfd>,rp
1017c218:	08 00 02 40 	nop
1017c21c:	08 1c 02 53 	copy ret0,r19

GR12 = 00027174

GR13 = ffffffff

GR14 = 00000000

GR15 = 00000000

GR16 = 103af5c0
Func: init_mm, Off: 0, Addr: 0x103af5c0

GR17 = 00027974

GR18 = ffffffff

GR19 = 10398010
Func: $global$, Off: 0, Addr: 0x10398010

GR20 = 00001000

GR21 = 00027753

GR22 = fffffff8

GR23 = 100bb9f4

GR24 = 00000000

GR25 = 10674558

GR26 = 00027752

GR27 = 10398010
Func: $global$, Off: 0, Addr: 0x10398010

GR28 = 00027752

GR29 = 00000000

GR30 = 10674680

GR31 = 40061077

Kernel symbols on the stack:
[<101639e4>]: Func: dentry_open, Off: f4, Addr: 0x101639e4
[<101342f8>]: Func: do_sigaction, Off: a8, Addr: 0x101342f8
[<1010bbf8>]: Func: handle_interruption, Off: 150, Addr: 0x1010bbf8
[<101346d4>]: Func: sys_rt_sigaction, Off: 84, Addr: 0x101346d4
[<10110f90>]: Func: syscall_exit, Off: 0, Addr: 0x10110f90
[<10110084>]: Func: intr_check_sig, Off: 0, Addr: 0x10110084
[<1010fcf4>]: Func: _switch_to_ret, Off: 0, Addr: 0x1010fcf4
[<10164e10>]: Func: chrdev_open, Off: 64, Addr: 0x10164e10
[<101639e4>]: Func: dentry_open, Off: f4, Addr: 0x101639e4
[<1017bfc4>]: Func: locate_fd, Off: 70, Addr: 0x1017bfc4
[<1017c21c>]: Func: sys_dup, Off: 28, Addr: 0x1017c21c
[<1012d9f4>]: Func: it_real_fn, Off: 0, Addr: 0x1012d9f4

Done.

It doesn't help me more right now (some sleep need :) ).

Thanks,
    Joel


---------------------------------
Vous surfez avec une ligne classique ?
Faites des economies avec Tiscali Complete
... Plus d'info sur http://complete.tiscali.be

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[b.gunreben]

Joel Soete wrote:
> >gcc 3.3 decides to not believe you want this function inlined.  probably
> >the right fix for this is to make this function static inline (you can
> >drop the `__' around inline, it's not necessary).  This is also the case
> >for linux 2.5.
> >
> Right Willy that allow to compile :)
> 
> Unfortunately it failled to boot :_( with following dump:
> Freeing unused kernel memory: 246k freed
> ......
> Submitted to dump_analyser.sh, I obtain:
> 
> IAOQ = 10351b7c
> Func: __canonicalize_funcptr_for_compare, Off: 38, Addr: 0x10351b7c
> 10351b70:       2a 6b 50 00     addil 56800,r19,%r1
> 10351b74:       48 21 0c a8     ldw 654(r1),r1
> 10351b78:       d4 60 1c 1e     depwi 0,31,2,r3
> 10351b7c:       0c 60 10 94     ldw 0(sr0,r3),r20
> 
> GR0 = 00000000
> 
> GR1 = 103eee50
> Func: _GLOBAL_OFFSET_TABLE_, Off: 0, Addr: 0x103eee50
> 
> GR2 = 101342f8
> Func: do_sigaction, Off: a8, Addr: 0x101342f8

I have the same problem with a gcc 3.3 compiled kernel. The kernel itself
completely comes up, and I even can call a static shell (something like
init=/bin/sash), but as soon as glibc is involved, the mentioned crash
occurs. Just to make it clear: I am able to use the builtin functions of
that shell (like ls) and this works.

This is independend from the kernel version (2.4 and 2.5 behave all the
same). The function __canonicalize_funcptr_for_compare seems to be newly
introduced in libgcc with gcc 3.3, and seems to be the cause of this error.


Berthold

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> This is independend from the kernel version (2.4 and 2.5 behave all the
> same). The function __canonicalize_funcptr_for_compare seems to be newly
> introduced in libgcc with gcc 3.3, and seems to be the cause of this error.

Do you have the same problem with a 3.0.4 built kernel?  I have been
using a 3.3 built glibc for some months now.

__canonicalize_funcptr_for_compare depends critically on the
the initial setup of function descriptors by the dynamic loader
and the trampoline in the dynamic loader used to resolve the
address of functions.  This could easily break if someone
unknowing messes with the pa specific parts of the dynamic
loader or the setup of function descriptors.

I'm building glibc-2.3.1-15 and should know soon if something
has changed.

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

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> This is independend from the kernel version (2.4 and 2.5 behave all the
> same). The function __canonicalize_funcptr_for_compare seems to be newly
> introduced in libgcc with gcc 3.3, and seems to be the cause of this error.

Do you have the same problem with a 3.0.4 built kernel?  I have been
using a 3.3 built glibc for some months now.

__canonicalize_funcptr_for_compare depends critically on the
the initial setup of function descriptors by the dynamic loader
and the trampoline in the dynamic loader used to resolve the
address of functions.  This could easily break if someone
unknowing messes with the pa specific parts of the dynamic
loader or the setup of function descriptors.

I'm building glibc-2.3.1-15 and should know soon if something
has changed.

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

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Randolph Chung]

> __canonicalize_funcptr_for_compare depends critically on the
> the initial setup of function descriptors by the dynamic loader
> and the trampoline in the dynamic loader used to resolve the
> address of functions.  This could easily break if someone
> unknowing messes with the pa specific parts of the dynamic
> loader or the setup of function descriptors.

um, Dave, we are talking about kernel here right? so no dynamic loader
is involved.

or did i misnuderstand you?
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> um, Dave, we are talking about kernel here right? so no dynamic loader
> is involved.
> 
> or did i misnuderstand you?
> randolph

I believe that we were talking about a problem in in glibc's use
of __canonicalize_funcptr_for_compare with a gcc 3.3 compiled kernel.

In any program with static linkage, the plabel bit shouldn't be
set in a function descriptor pointer.  In that case,
__canonicalize_funcptr_for_compare just returns the function
descriptor pointer.  Things only get hairy when the dynamic loader
is involved and the routine has to figure out the address of
the function fixup in the dynamic loader.

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

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> um, Dave, we are talking about kernel here right? so no dynamic loader
> is involved.
> 
> or did i misnuderstand you?
> randolph

I believe that we were talking about a problem in in glibc's use
of __canonicalize_funcptr_for_compare with a gcc 3.3 compiled kernel.

In any program with static linkage, the plabel bit shouldn't be
set in a function descriptor pointer.  In that case,
__canonicalize_funcptr_for_compare just returns the function
descriptor pointer.  Things only get hairy when the dynamic loader
is involved and the routine has to figure out the address of
the function fixup in the dynamic loader.

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

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Randolph Chung]

> I believe that we were talking about a problem in in glibc's use
> of __canonicalize_funcptr_for_compare with a gcc 3.3 compiled kernel.

Quoting an earlier mail:
> IAOQ = 10351b7c
> Func: __canonicalize_funcptr_for_compare, Off: 38, Addr: 0x10351b7c
> 10351b70:       2a 6b 50 00     addil 56800,r19,%r1
> 10351b74:       48 21 0c a8     ldw 654(r1),r1
> 10351b78:       d4 60 1c 1e     depwi 0,31,2,r3
> 10351b7c:       0c 60 10 94     ldw 0(sr0,r3),r20
>
> GR0 = 00000000
>
> GR1 = 103eee50
> Func: _GLOBAL_OFFSET_TABLE_, Off: 0, Addr: 0x103eee50
>
> GR2 = 101342f8
> Func: do_sigaction, Off: a8, Addr: 0x101342f8

these are definitely kernel addresses....

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> > I believe that we were talking about a problem in in glibc's use
> > of __canonicalize_funcptr_for_compare with a gcc 3.3 compiled kernel.
> 
> Quoting an earlier mail:
> > IAOQ = 10351b7c
> > Func: __canonicalize_funcptr_for_compare, Off: 38, Addr: 0x10351b7c
> > 10351b70:       2a 6b 50 00     addil 56800,r19,%r1
> > 10351b74:       48 21 0c a8     ldw 654(r1),r1
> > 10351b78:       d4 60 1c 1e     depwi 0,31,2,r3
> > 10351b7c:       0c 60 10 94     ldw 0(sr0,r3),r20
> >
> > GR0 = 00000000
> >
> > GR1 = 103eee50
> > Func: _GLOBAL_OFFSET_TABLE_, Off: 0, Addr: 0x103eee50
> >
> > GR2 = 101342f8
> > Func: do_sigaction, Off: a8, Addr: 0x101342f8
> 
> these are definitely kernel addresses....

Right.  I see the code that's causing the problem in kernel/signal.c:

                if (k->sa.sa_handler == SIG_IGN
		    || (k->sa.sa_handler == SIG_DFL


You don't want to canonicalize k->sa.sa_handler here, so a cast to
void * or something is needed.  The PA is the only port that I am
aware of that needs to canonicalize function pointers.

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

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> > I believe that we were talking about a problem in in glibc's use
> > of __canonicalize_funcptr_for_compare with a gcc 3.3 compiled kernel.
> 
> Quoting an earlier mail:
> > IAOQ = 10351b7c
> > Func: __canonicalize_funcptr_for_compare, Off: 38, Addr: 0x10351b7c
> > 10351b70:       2a 6b 50 00     addil 56800,r19,%r1
> > 10351b74:       48 21 0c a8     ldw 654(r1),r1
> > 10351b78:       d4 60 1c 1e     depwi 0,31,2,r3
> > 10351b7c:       0c 60 10 94     ldw 0(sr0,r3),r20
> >
> > GR0 = 00000000
> >
> > GR1 = 103eee50
> > Func: _GLOBAL_OFFSET_TABLE_, Off: 0, Addr: 0x103eee50
> >
> > GR2 = 101342f8
> > Func: do_sigaction, Off: a8, Addr: 0x101342f8
> 
> these are definitely kernel addresses....

Right.  I see the code that's causing the problem in kernel/signal.c:

                if (k->sa.sa_handler == SIG_IGN
		    || (k->sa.sa_handler == SIG_DFL


You don't want to canonicalize k->sa.sa_handler here, so a cast to
void * or something is needed.  The PA is the only port that I am
aware of that needs to canonicalize function pointers.

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

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

>> 
>> these are definitely kernel addresses....
>
>Right.  I see the code that's causing the problem in kernel/signal.c:
>
>                if (k->sa.sa_handler == SIG_IGN
>		    || (k->sa.sa_handler == SIG_DFL
>
>
>You don't want to canonicalize k->sa.sa_handler here, so a cast to
>void * or something is needed.  The PA is the only port that I am
>aware of that needs to canonicalize function pointers.
>
Well I try to test some:
--- signal.h.orig       2003-03-20 15:12:24.000000000 +0100
+++ signal.h    2003-03-20 15:11:47.000000000 +0100
@@ -106,9 +106,15 @@
 #define SIG_UNBLOCK        1   /* for unblocking signals */
 #define SIG_SETMASK        2   /* for setting the signal mask */
 
+#if __GNUC__ == 3 && __GNUC_MINOR__ >= 3 || __GNUC__ > 3
+#define SIG_DFL        (0)                     /* default signal handling
*/
+#define SIG_IGN        (1)                     /* ignore signal */
+#define SIG_ERR        (-1)                    /* error return from signal
*/
+#else
 #define SIG_DFL        ((__sighandler_t)0)     /* default signal handling
*/
 #define SIG_IGN        ((__sighandler_t)1)     /* ignore signal */
 #define SIG_ERR        ((__sighandler_t)-1)    /* error return from signal
*/
+#endif
 
 # ifndef __ASSEMBLY__

Unfortunaltely, I don't actualy know if it could help because I update kernel
src to pa31 and the problem move to:

IAOQ = 102f1e6c
Func: $lcfu_loop, Off: 0, Addr: 0x102f1e6c
102f1e60:	08 16 32 40 	or,<> r22,r0,r0
102f1e64:	08 00 02 41 	copy r0,r1
102f1e68:	00 01 58 20 	mtsp r1,sr1
102f1e6c <$lcfu_loop>:
102f1e6c:	0f 22 50 21 	ldb,ma 1(sr1,r25),r1
102f1e70:	af 1f 3f ed 	addib,<> -1,r24,102f1e6c <$lcfu_loop>

GR0 = 00000000

GR1 = 000000dd

GR2 = 1016dd94
Func: copy_mount_options, Off: 70, Addr: 0x1016dd94
1016dd90:	08 04 02 58 	copy r4,r24
1016dd94:	0b 84 04 04 	sub r4,ret0,r4
1016dd98:	08 03 02 5a 	copy r3,r26
1016dd9c:	84 80 20 70 	cmpib,= 0,r4,1016dddc <copy_mount_options+0xb8>

GR3 = 1ffb9000

GR4 = 00001000

GR5 = 1ffff005

GR6 = 00001000

GR7 = 107c8788

GR8 = 103ab810
Func: packet_init, Off: 3c, Addr: 0x103ab810
103ab810:	87 80 20 18 	cmpib,= 0,ret0,103ab824 <packet_init+0x50>
103ab814:	22 72 12 06 	ldil 10324800,r19
103ab818:	4a 74 09 48 	ldw 4a4(r19),r20
103ab81c:	6b 80 00 68 	stw r0,34(ret0)

GR9 = 103e0010
Func: Version_132116, Off: 0, Addr: 0x103e0010

GR10 = 10418010
Func: blkdevs, Off: 4e4, Addr: 0x10418010

GR11 = 102f8000
Func: ic_bootp_cookie, Off: 440, Addr: 0x102f8000

GR12 = 10340810
Func: syscall_names, Off: 49c, Addr: 0x10340810

GR13 = 10413810
Func: log_buf, Off: 79e4, Addr: 0x10413810

GR14 = 00000000

GR15 = f0400004

GR16 = f00008c4

GR17 = f000017c

GR18 = f0000174

GR19 = 107c8000

GR20 = bffd00d5

GR21 = f0047000

GR22 = 00000000

GR23 = 00000000

GR24 = 00000005

GR25 = 20000000

GR26 = 1ffb9ffb

GR27 = 10330010
Func: $global$, Off: 0, Addr: 0x10330010

GR28 = fffffff4

GR29 = 80dea173

GR30 = 107c8880

GR31 = 101563e4
Func: blkdev_put, Off: 1f4, Addr: 0x101563e4
101562bc:	86 60 22 50 	cmpib,= 0,r19,101563ec <blkdev_put+0x1fc>
101563e0:	08 1f 02 42 	copy r31,rp
101563e4:	c9 1c 9d d5 	movb,tr ret0,r8,101562d4 <blkdev_put+0xe4>
101563e8:	48 b3 00 30 	ldw 18(r5),r19
101563ec:	08 05 02 5a 	copy r5,r26

Kernel symbols on the stack:
[<1016dd60>]: Func: copy_mount_options, Off: 3c, Addr: 0x1016dd60
[<1016e5e8>]: Func: sys_mount, Off: 30, Addr: 0x1016e5e8
[<101004b8>]: Func: prepare_namespace, Off: bc, Addr: 0x101004b8
[<10100240>]: Func: init, Off: 58, Addr: 0x10100240
[<10108c4c>]: Func: ret_from_kernel_thread, Off: 18, Addr: 0x10108c4c
[<10108cf4>]: Func: _switch_to_ret, Off: 0, Addr: 0x10108cf4
[<1012187c>]: Func: call_console_drivers, Off: b8, Addr: 0x1012187c
[<1012187c>]: Func: call_console_drivers, Off: b8, Addr: 0x1012187c
[<10121d2c>]: Func: release_console_sem, Off: 50, Addr: 0x10121d2c
[<10121b94>]: Func: printk, Off: 1f0, Addr: 0x10121b94
[<101001e8>]: Func: init, Off: 0, Addr: 0x101001e8
[<10126488>]: Func: it_real_fn, Off: 0, Addr: 0x10126488

Any other additional idea?

Thanks,
    Joel


---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

>> 
>> these are definitely kernel addresses....
>
>Right.  I see the code that's causing the problem in kernel/signal.c:
>
>                if (k->sa.sa_handler == SIG_IGN
>		    || (k->sa.sa_handler == SIG_DFL
>
>
>You don't want to canonicalize k->sa.sa_handler here, so a cast to
>void * or something is needed.  The PA is the only port that I am
>aware of that needs to canonicalize function pointers.
>
Well I try to test some:
--- signal.h.orig       2003-03-20 15:12:24.000000000 +0100
+++ signal.h    2003-03-20 15:11:47.000000000 +0100
@@ -106,9 +106,15 @@
 #define SIG_UNBLOCK        1   /* for unblocking signals */
 #define SIG_SETMASK        2   /* for setting the signal mask */
 
+#if __GNUC__ == 3 && __GNUC_MINOR__ >= 3 || __GNUC__ > 3
+#define SIG_DFL        (0)                     /* default signal handling
*/
+#define SIG_IGN        (1)                     /* ignore signal */
+#define SIG_ERR        (-1)                    /* error return from signal
*/
+#else
 #define SIG_DFL        ((__sighandler_t)0)     /* default signal handling
*/
 #define SIG_IGN        ((__sighandler_t)1)     /* ignore signal */
 #define SIG_ERR        ((__sighandler_t)-1)    /* error return from signal
*/
+#endif
 
 # ifndef __ASSEMBLY__

Unfortunaltely, I don't actualy know if it could help because I update kernel
src to pa31 and the problem move to:

IAOQ = 102f1e6c
Func: $lcfu_loop, Off: 0, Addr: 0x102f1e6c
102f1e60:	08 16 32 40 	or,<> r22,r0,r0
102f1e64:	08 00 02 41 	copy r0,r1
102f1e68:	00 01 58 20 	mtsp r1,sr1
102f1e6c <$lcfu_loop>:
102f1e6c:	0f 22 50 21 	ldb,ma 1(sr1,r25),r1
102f1e70:	af 1f 3f ed 	addib,<> -1,r24,102f1e6c <$lcfu_loop>

GR0 = 00000000

GR1 = 000000dd

GR2 = 1016dd94
Func: copy_mount_options, Off: 70, Addr: 0x1016dd94
1016dd90:	08 04 02 58 	copy r4,r24
1016dd94:	0b 84 04 04 	sub r4,ret0,r4
1016dd98:	08 03 02 5a 	copy r3,r26
1016dd9c:	84 80 20 70 	cmpib,= 0,r4,1016dddc <copy_mount_options+0xb8>

GR3 = 1ffb9000

GR4 = 00001000

GR5 = 1ffff005

GR6 = 00001000

GR7 = 107c8788

GR8 = 103ab810
Func: packet_init, Off: 3c, Addr: 0x103ab810
103ab810:	87 80 20 18 	cmpib,= 0,ret0,103ab824 <packet_init+0x50>
103ab814:	22 72 12 06 	ldil 10324800,r19
103ab818:	4a 74 09 48 	ldw 4a4(r19),r20
103ab81c:	6b 80 00 68 	stw r0,34(ret0)

GR9 = 103e0010
Func: Version_132116, Off: 0, Addr: 0x103e0010

GR10 = 10418010
Func: blkdevs, Off: 4e4, Addr: 0x10418010

GR11 = 102f8000
Func: ic_bootp_cookie, Off: 440, Addr: 0x102f8000

GR12 = 10340810
Func: syscall_names, Off: 49c, Addr: 0x10340810

GR13 = 10413810
Func: log_buf, Off: 79e4, Addr: 0x10413810

GR14 = 00000000

GR15 = f0400004

GR16 = f00008c4

GR17 = f000017c

GR18 = f0000174

GR19 = 107c8000

GR20 = bffd00d5

GR21 = f0047000

GR22 = 00000000

GR23 = 00000000

GR24 = 00000005

GR25 = 20000000

GR26 = 1ffb9ffb

GR27 = 10330010
Func: $global$, Off: 0, Addr: 0x10330010

GR28 = fffffff4

GR29 = 80dea173

GR30 = 107c8880

GR31 = 101563e4
Func: blkdev_put, Off: 1f4, Addr: 0x101563e4
101562bc:	86 60 22 50 	cmpib,= 0,r19,101563ec <blkdev_put+0x1fc>
101563e0:	08 1f 02 42 	copy r31,rp
101563e4:	c9 1c 9d d5 	movb,tr ret0,r8,101562d4 <blkdev_put+0xe4>
101563e8:	48 b3 00 30 	ldw 18(r5),r19
101563ec:	08 05 02 5a 	copy r5,r26

Kernel symbols on the stack:
[<1016dd60>]: Func: copy_mount_options, Off: 3c, Addr: 0x1016dd60
[<1016e5e8>]: Func: sys_mount, Off: 30, Addr: 0x1016e5e8
[<101004b8>]: Func: prepare_namespace, Off: bc, Addr: 0x101004b8
[<10100240>]: Func: init, Off: 58, Addr: 0x10100240
[<10108c4c>]: Func: ret_from_kernel_thread, Off: 18, Addr: 0x10108c4c
[<10108cf4>]: Func: _switch_to_ret, Off: 0, Addr: 0x10108cf4
[<1012187c>]: Func: call_console_drivers, Off: b8, Addr: 0x1012187c
[<1012187c>]: Func: call_console_drivers, Off: b8, Addr: 0x1012187c
[<10121d2c>]: Func: release_console_sem, Off: 50, Addr: 0x10121d2c
[<10121b94>]: Func: printk, Off: 1f0, Addr: 0x10121b94
[<101001e8>]: Func: init, Off: 0, Addr: 0x101001e8
[<10126488>]: Func: it_real_fn, Off: 0, Addr: 0x10126488

Any other additional idea?

Thanks,
    Joel


---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> >> 
> >> these are definitely kernel addresses....
> >
> >Right.  I see the code that's causing the problem in kernel/signal.c:
> >
> >                if (k->sa.sa_handler == SIG_IGN
> >		    || (k->sa.sa_handler == SIG_DFL
> >
> >
> >You don't want to canonicalize k->sa.sa_handler here, so a cast to
> >void * or something is needed.  The PA is the only port that I am
> >aware of that needs to canonicalize function pointers.
> >
> Well I try to test some:
> --- signal.h.orig       2003-03-20 15:12:24.000000000 +0100
> +++ signal.h    2003-03-20 15:11:47.000000000 +0100
> @@ -106,9 +106,15 @@
>  #define SIG_UNBLOCK        1   /* for unblocking signals */
>  #define SIG_SETMASK        2   /* for setting the signal mask */
>  
> +#if __GNUC__ == 3 && __GNUC_MINOR__ >= 3 || __GNUC__ > 3
> +#define SIG_DFL        (0)                     /* default signal handling
> */
> +#define SIG_IGN        (1)                     /* ignore signal */
> +#define SIG_ERR        (-1)                    /* error return from signal
> */
> +#else
>  #define SIG_DFL        ((__sighandler_t)0)     /* default signal handling
> */
>  #define SIG_IGN        ((__sighandler_t)1)     /* ignore signal */
>  #define SIG_ERR        ((__sighandler_t)-1)    /* error return from signal
> */
> +#endif

No, don't do that.  SIG_DFL, SIG_IGN and SIG_ERR expand to compound
literals.  Look at the assembly output from the following little
program (gcc -S) with and without the "void *" cast.

typedef int (*__sighandler_t)(void);
#define SIG_IGN        ((__sighandler_t)1)
int foo (__sighandler_t g)
{
  return g == (void *)SIG_IGN;
}

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

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> No, don't do that.  SIG_DFL, SIG_IGN and SIG_ERR expand to compound
> literals.

Sorry, that part is wrong.  Anyway, just leave the macro defines as
is and cast them where used to void *.  This causes the conversion
of the other operand to void * and function pointer conicalization
won't be done (6.5.9, paragraph 5).

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

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> No, don't do that.  SIG_DFL, SIG_IGN and SIG_ERR expand to compound
> literals.

Sorry, that part is wrong.  Anyway, just leave the macro defines as
is and cast them where used to void *.  This causes the conversion
of the other operand to void * and function pointer conicalization
won't be done (6.5.9, paragraph 5).

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

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

[-- Attachment #1: Type: text/plain, Size: 8303 bytes --]

Hi Dave,
>
>Sorry, that part is wrong.  Anyway, just leave the macro defines as
>is and cast them where used to void *.  This causes the conversion
>of the other operand to void * and function pointer conicalization
>won't be done (6.5.9, paragraph 5).
>
you have definitely right.

I test following work-around against 2.4.20-pa32 with latest dpkg gcc-3.3
(3.3-0pre2) and it boot well know:
=====
diff -Naur linux-2.4.20-pa32/Makefile linux-2.4.20-pa32-gcc33/Makefile
--- linux-2.4.20-pa32/Makefile	2003-03-21 12:17:41.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/Makefile	2003-03-21 12:19:06.000000000 +0100
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 4
 SUBLEVEL = 20
-EXTRAVERSION = -pa32
+EXTRAVERSION = -pa33
 
 KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
 
diff -Naur linux-2.4.20-pa32/arch/parisc/kernel/signal.c linux-2.4.20-pa32-gcc33/arch/parisc/kernel/signal.c
--- linux-2.4.20-pa32/arch/parisc/kernel/signal.c	2003-03-21 10:54:23.000000000
+0100
+++ linux-2.4.20-pa32-gcc33/arch/parisc/kernel/signal.c	2003-03-21 12:39:20.000000000
+0100
@@ -489,7 +489,11 @@
 		ka = &current->sig->action[signr-1];
 		DBG(("sa_handler is %x\n", 
 			(unsigned int) ka->sa.sa_handler));
+#if !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__
>= 1))
+		if (ka->sa.sa_handler == (void *)SIG_IGN) {
+#else
 		if (ka->sa.sa_handler == SIG_IGN) {
+#endif
 			if (signr != SIGCHLD)
 				continue;
 			while (sys_wait4(-1, NULL, WNOHANG, NULL) > 0)
@@ -497,7 +501,11 @@
 			continue;
 		}
 
+#if !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__
>= 1))
+		if (ka->sa.sa_handler == (void *)SIG_DFL) {
+#else
 		if (ka->sa.sa_handler == SIG_DFL) {
+#endif
 			int exit_code = signr;
 
 			/* Init gets no signals it doesn't want.  */
diff -Naur linux-2.4.20-pa32/drivers/char/n_tty.c linux-2.4.20-pa32-gcc33/drivers/char/n_tty.c
--- linux-2.4.20-pa32/drivers/char/n_tty.c	2003-03-21 10:51:30.000000000
+0100
+++ linux-2.4.20-pa32-gcc33/drivers/char/n_tty.c	2003-03-21 12:34:35.000000000
+0100
@@ -810,7 +810,11 @@
 int is_ignored(int sig)
 {
 	return (sigismember(&current->blocked, sig) ||
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+	        current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN);
+#else
 	        current->sig->action[sig-1].sa.sa_handler == SIG_IGN);
+#endif
 }
 
 static void n_tty_set_termios(struct tty_struct *tty, struct termios * old)
diff -Naur linux-2.4.20-pa32/fs/ncpfs/sock.c linux-2.4.20-pa32-gcc33/fs/ncpfs/sock.c
--- linux-2.4.20-pa32/fs/ncpfs/sock.c	2003-03-21 10:36:05.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/fs/ncpfs/sock.c	2003-03-21 12:35:37.000000000
+0100
@@ -466,9 +466,17 @@
 			   What if we've blocked it ourselves?  What about
 			   alarms?  Why, in fact, are we mucking with the
 			   sigmask at all? -- r~ */
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+			if (current->sig->action[SIGINT - 1].sa.sa_handler == (void *)SIG_DFL)
+#else
 			if (current->sig->action[SIGINT - 1].sa.sa_handler == SIG_DFL)
+#endif
 				mask |= sigmask(SIGINT);
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+			if (current->sig->action[SIGQUIT - 1].sa.sa_handler == (void *)SIG_DFL)
+#else
 			if (current->sig->action[SIGQUIT - 1].sa.sa_handler == SIG_DFL)
+#endif
 				mask |= sigmask(SIGQUIT);
 		}
 		siginitsetinv(&current->blocked, mask);
diff -Naur linux-2.4.20-pa32/fs/proc/array.c linux-2.4.20-pa32-gcc33/fs/proc/array.c
--- linux-2.4.20-pa32/fs/proc/array.c	2003-03-21 10:01:18.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/fs/proc/array.c	2003-03-21 12:36:44.000000000
+0100
@@ -231,9 +231,17 @@
 	if (p->sig) {
 		k = p->sig->action;
 		for (i = 1; i <= _NSIG; ++i, ++k) {
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+			if (k->sa.sa_handler == (void *)SIG_IGN)
+#else
 			if (k->sa.sa_handler == SIG_IGN)
+#endif
 				sigaddset(ign, i);
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+			else if (k->sa.sa_handler != (void *)SIG_DFL)
+#else
 			else if (k->sa.sa_handler != SIG_DFL)
+#endif
 				sigaddset(catch, i);
 		}
 	}
diff -Naur linux-2.4.20-pa32/include/linux/compiler.h linux-2.4.20-pa32-gcc33/include/linux/compiler.h
--- linux-2.4.20-pa32/include/linux/compiler.h	2003-03-21 12:31:39.000000000
+0100
+++ linux-2.4.20-pa32-gcc33/include/linux/compiler.h	2003-03-21 12:32:07.000000000
+0100
@@ -1,6 +1,12 @@
 #ifndef __LINUX_COMPILER_H
 #define __LINUX_COMPILER_H
 
+#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
+#define inline		__inline__ __attribute__((always_inline))
+#define __inline__	__inline__ __attribute__((always_inline))
+#define __inline	__inline__ __attribute__((always_inline))
+#endif
+
 /* Somewhere in the middle of the GCC 2.96 development cycle, we implemented
    a mechanism by which the user can annotate likely branch directions and
    expect the blocks to be reordered appropriately.  Define __builtin_expect
diff -Naur linux-2.4.20-pa32/kernel/signal.c linux-2.4.20-pa32-gcc33/kernel/signal.c
--- linux-2.4.20-pa32/kernel/signal.c	2003-03-21 10:39:32.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/kernel/signal.c	2003-03-21 12:37:40.000000000
+0100
@@ -126,7 +126,11 @@
 	int i;
 	struct k_sigaction *ka = &t->sig->action[0];
 	for (i = _NSIG ; i != 0 ; i--) {
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+		if (ka->sa.sa_handler != (void *)SIG_IGN)
+#else
 		if (ka->sa.sa_handler != SIG_IGN)
+#endif
 			ka->sa.sa_handler = SIG_DFL;
 		ka->sa.sa_flags = 0;
 		sigemptyset(&ka->sa.sa_mask);
@@ -572,7 +576,11 @@
 		return -ESRCH;
 	}
 
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+	if (t->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN)
+#else
 	if (t->sig->action[sig-1].sa.sa_handler == SIG_IGN)
+#endif
 		t->sig->action[sig-1].sa.sa_handler = SIG_DFL;
 	sigdelset(&t->blocked, sig);
 	recalc_sigpending(t);
@@ -1094,8 +1102,13 @@
 		 * the signal to be ignored.
 		 */
 
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+		if (k->sa.sa_handler == (void *)SIG_IGN
+		    || (k->sa.sa_handler == (void *)SIG_DFL
+#else
 		if (k->sa.sa_handler == SIG_IGN
 		    || (k->sa.sa_handler == SIG_DFL
+#endif
 			&& (sig == SIGCONT ||
 			    sig == SIGCHLD ||
 			    sig == SIGURG ||
diff -Naur linux-2.4.20-pa32/net/sunrpc/clnt.c linux-2.4.20-pa32-gcc33/net/sunrpc/clnt.c
--- linux-2.4.20-pa32/net/sunrpc/clnt.c	2003-03-21 10:46:28.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/net/sunrpc/clnt.c	2003-03-21 12:38:07.000000000
+0100
@@ -209,9 +209,17 @@
 	/* Turn off various signals */
 	if (clnt->cl_intr) {
 		struct k_sigaction *action = current->sig->action;
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+		if (action[SIGINT-1].sa.sa_handler == (void *)SIG_DFL)
+#else
 		if (action[SIGINT-1].sa.sa_handler == SIG_DFL)
+#endif
 			sigallow |= sigmask(SIGINT);
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+		if (action[SIGQUIT-1].sa.sa_handler == (void *)SIG_DFL)
+#else
 		if (action[SIGQUIT-1].sa.sa_handler == SIG_DFL)
+#endif
 			sigallow |= sigmask(SIGQUIT);
 	}
 	spin_lock_irqsave(&current->sigmask_lock, irqflags);
=====

I could not be sure about __LP64__ condition because gcc-hppa62_3.3 do not
yet exist :(

Can some body else could test it more?

Joel

PS1: I hoppe it will stay just a temporary work-around; that is typical what
I hate: code depending of platform and more over compiler release :(

PS2: If I well understand the pa32 patch include the Alan patch concerning
ptrace vulnerability. Is there some simple mean to stress the solution on
hppa platform?

---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be



[-- Attachment #2: linux-2.4.20-pa32_gcc33.patch --]
[-- Type: application/octet-stream, Size: 7228 bytes --]

diff -Naur linux-2.4.20-pa32/Makefile linux-2.4.20-pa32-gcc33/Makefile
--- linux-2.4.20-pa32/Makefile	2003-03-21 12:17:41.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/Makefile	2003-03-21 12:19:06.000000000 +0100
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 4
 SUBLEVEL = 20
-EXTRAVERSION = -pa32
+EXTRAVERSION = -pa33
 
 KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
 
diff -Naur linux-2.4.20-pa32/arch/parisc/kernel/signal.c linux-2.4.20-pa32-gcc33/arch/parisc/kernel/signal.c
--- linux-2.4.20-pa32/arch/parisc/kernel/signal.c	2003-03-21 10:54:23.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/arch/parisc/kernel/signal.c	2003-03-21 12:39:20.000000000 +0100
@@ -489,7 +489,11 @@
 		ka = &current->sig->action[signr-1];
 		DBG(("sa_handler is %x\n", 
 			(unsigned int) ka->sa.sa_handler));
+#if !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+		if (ka->sa.sa_handler == (void *)SIG_IGN) {
+#else
 		if (ka->sa.sa_handler == SIG_IGN) {
+#endif
 			if (signr != SIGCHLD)
 				continue;
 			while (sys_wait4(-1, NULL, WNOHANG, NULL) > 0)
@@ -497,7 +501,11 @@
 			continue;
 		}
 
+#if !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+		if (ka->sa.sa_handler == (void *)SIG_DFL) {
+#else
 		if (ka->sa.sa_handler == SIG_DFL) {
+#endif
 			int exit_code = signr;
 
 			/* Init gets no signals it doesn't want.  */
diff -Naur linux-2.4.20-pa32/drivers/char/n_tty.c linux-2.4.20-pa32-gcc33/drivers/char/n_tty.c
--- linux-2.4.20-pa32/drivers/char/n_tty.c	2003-03-21 10:51:30.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/drivers/char/n_tty.c	2003-03-21 12:34:35.000000000 +0100
@@ -810,7 +810,11 @@
 int is_ignored(int sig)
 {
 	return (sigismember(&current->blocked, sig) ||
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+	        current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN);
+#else
 	        current->sig->action[sig-1].sa.sa_handler == SIG_IGN);
+#endif
 }
 
 static void n_tty_set_termios(struct tty_struct *tty, struct termios * old)
diff -Naur linux-2.4.20-pa32/fs/ncpfs/sock.c linux-2.4.20-pa32-gcc33/fs/ncpfs/sock.c
--- linux-2.4.20-pa32/fs/ncpfs/sock.c	2003-03-21 10:36:05.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/fs/ncpfs/sock.c	2003-03-21 12:35:37.000000000 +0100
@@ -466,9 +466,17 @@
 			   What if we've blocked it ourselves?  What about
 			   alarms?  Why, in fact, are we mucking with the
 			   sigmask at all? -- r~ */
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+			if (current->sig->action[SIGINT - 1].sa.sa_handler == (void *)SIG_DFL)
+#else
 			if (current->sig->action[SIGINT - 1].sa.sa_handler == SIG_DFL)
+#endif
 				mask |= sigmask(SIGINT);
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+			if (current->sig->action[SIGQUIT - 1].sa.sa_handler == (void *)SIG_DFL)
+#else
 			if (current->sig->action[SIGQUIT - 1].sa.sa_handler == SIG_DFL)
+#endif
 				mask |= sigmask(SIGQUIT);
 		}
 		siginitsetinv(&current->blocked, mask);
diff -Naur linux-2.4.20-pa32/fs/proc/array.c linux-2.4.20-pa32-gcc33/fs/proc/array.c
--- linux-2.4.20-pa32/fs/proc/array.c	2003-03-21 10:01:18.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/fs/proc/array.c	2003-03-21 12:36:44.000000000 +0100
@@ -231,9 +231,17 @@
 	if (p->sig) {
 		k = p->sig->action;
 		for (i = 1; i <= _NSIG; ++i, ++k) {
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+			if (k->sa.sa_handler == (void *)SIG_IGN)
+#else
 			if (k->sa.sa_handler == SIG_IGN)
+#endif
 				sigaddset(ign, i);
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+			else if (k->sa.sa_handler != (void *)SIG_DFL)
+#else
 			else if (k->sa.sa_handler != SIG_DFL)
+#endif
 				sigaddset(catch, i);
 		}
 	}
diff -Naur linux-2.4.20-pa32/include/linux/compiler.h linux-2.4.20-pa32-gcc33/include/linux/compiler.h
--- linux-2.4.20-pa32/include/linux/compiler.h	2003-03-21 12:31:39.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/include/linux/compiler.h	2003-03-21 12:32:07.000000000 +0100
@@ -1,6 +1,12 @@
 #ifndef __LINUX_COMPILER_H
 #define __LINUX_COMPILER_H
 
+#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
+#define inline		__inline__ __attribute__((always_inline))
+#define __inline__	__inline__ __attribute__((always_inline))
+#define __inline	__inline__ __attribute__((always_inline))
+#endif
+
 /* Somewhere in the middle of the GCC 2.96 development cycle, we implemented
    a mechanism by which the user can annotate likely branch directions and
    expect the blocks to be reordered appropriately.  Define __builtin_expect
diff -Naur linux-2.4.20-pa32/kernel/signal.c linux-2.4.20-pa32-gcc33/kernel/signal.c
--- linux-2.4.20-pa32/kernel/signal.c	2003-03-21 10:39:32.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/kernel/signal.c	2003-03-21 12:37:40.000000000 +0100
@@ -126,7 +126,11 @@
 	int i;
 	struct k_sigaction *ka = &t->sig->action[0];
 	for (i = _NSIG ; i != 0 ; i--) {
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+		if (ka->sa.sa_handler != (void *)SIG_IGN)
+#else
 		if (ka->sa.sa_handler != SIG_IGN)
+#endif
 			ka->sa.sa_handler = SIG_DFL;
 		ka->sa.sa_flags = 0;
 		sigemptyset(&ka->sa.sa_mask);
@@ -572,7 +576,11 @@
 		return -ESRCH;
 	}
 
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+	if (t->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN)
+#else
 	if (t->sig->action[sig-1].sa.sa_handler == SIG_IGN)
+#endif
 		t->sig->action[sig-1].sa.sa_handler = SIG_DFL;
 	sigdelset(&t->blocked, sig);
 	recalc_sigpending(t);
@@ -1094,8 +1102,13 @@
 		 * the signal to be ignored.
 		 */
 
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+		if (k->sa.sa_handler == (void *)SIG_IGN
+		    || (k->sa.sa_handler == (void *)SIG_DFL
+#else
 		if (k->sa.sa_handler == SIG_IGN
 		    || (k->sa.sa_handler == SIG_DFL
+#endif
 			&& (sig == SIGCONT ||
 			    sig == SIGCHLD ||
 			    sig == SIGURG ||
diff -Naur linux-2.4.20-pa32/net/sunrpc/clnt.c linux-2.4.20-pa32-gcc33/net/sunrpc/clnt.c
--- linux-2.4.20-pa32/net/sunrpc/clnt.c	2003-03-21 10:46:28.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/net/sunrpc/clnt.c	2003-03-21 12:38:07.000000000 +0100
@@ -209,9 +209,17 @@
 	/* Turn off various signals */
 	if (clnt->cl_intr) {
 		struct k_sigaction *action = current->sig->action;
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+		if (action[SIGINT-1].sa.sa_handler == (void *)SIG_DFL)
+#else
 		if (action[SIGINT-1].sa.sa_handler == SIG_DFL)
+#endif
 			sigallow |= sigmask(SIGINT);
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+		if (action[SIGQUIT-1].sa.sa_handler == (void *)SIG_DFL)
+#else
 		if (action[SIGQUIT-1].sa.sa_handler == SIG_DFL)
+#endif
 			sigallow |= sigmask(SIGQUIT);
 	}
 	spin_lock_irqsave(&current->sigmask_lock, irqflags);

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

[-- Attachment #1: Type: text/plain, Size: 8303 bytes --]

Hi Dave,
>
>Sorry, that part is wrong.  Anyway, just leave the macro defines as
>is and cast them where used to void *.  This causes the conversion
>of the other operand to void * and function pointer conicalization
>won't be done (6.5.9, paragraph 5).
>
you have definitely right.

I test following work-around against 2.4.20-pa32 with latest dpkg gcc-3.3
(3.3-0pre2) and it boot well know:
=====
diff -Naur linux-2.4.20-pa32/Makefile linux-2.4.20-pa32-gcc33/Makefile
--- linux-2.4.20-pa32/Makefile	2003-03-21 12:17:41.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/Makefile	2003-03-21 12:19:06.000000000 +0100
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 4
 SUBLEVEL = 20
-EXTRAVERSION = -pa32
+EXTRAVERSION = -pa33
 
 KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
 
diff -Naur linux-2.4.20-pa32/arch/parisc/kernel/signal.c linux-2.4.20-pa32-gcc33/arch/parisc/kernel/signal.c
--- linux-2.4.20-pa32/arch/parisc/kernel/signal.c	2003-03-21 10:54:23.000000000
+0100
+++ linux-2.4.20-pa32-gcc33/arch/parisc/kernel/signal.c	2003-03-21 12:39:20.000000000
+0100
@@ -489,7 +489,11 @@
 		ka = &current->sig->action[signr-1];
 		DBG(("sa_handler is %x\n", 
 			(unsigned int) ka->sa.sa_handler));
+#if !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__
>= 1))
+		if (ka->sa.sa_handler == (void *)SIG_IGN) {
+#else
 		if (ka->sa.sa_handler == SIG_IGN) {
+#endif
 			if (signr != SIGCHLD)
 				continue;
 			while (sys_wait4(-1, NULL, WNOHANG, NULL) > 0)
@@ -497,7 +501,11 @@
 			continue;
 		}
 
+#if !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__
>= 1))
+		if (ka->sa.sa_handler == (void *)SIG_DFL) {
+#else
 		if (ka->sa.sa_handler == SIG_DFL) {
+#endif
 			int exit_code = signr;
 
 			/* Init gets no signals it doesn't want.  */
diff -Naur linux-2.4.20-pa32/drivers/char/n_tty.c linux-2.4.20-pa32-gcc33/drivers/char/n_tty.c
--- linux-2.4.20-pa32/drivers/char/n_tty.c	2003-03-21 10:51:30.000000000
+0100
+++ linux-2.4.20-pa32-gcc33/drivers/char/n_tty.c	2003-03-21 12:34:35.000000000
+0100
@@ -810,7 +810,11 @@
 int is_ignored(int sig)
 {
 	return (sigismember(&current->blocked, sig) ||
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+	        current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN);
+#else
 	        current->sig->action[sig-1].sa.sa_handler == SIG_IGN);
+#endif
 }
 
 static void n_tty_set_termios(struct tty_struct *tty, struct termios * old)
diff -Naur linux-2.4.20-pa32/fs/ncpfs/sock.c linux-2.4.20-pa32-gcc33/fs/ncpfs/sock.c
--- linux-2.4.20-pa32/fs/ncpfs/sock.c	2003-03-21 10:36:05.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/fs/ncpfs/sock.c	2003-03-21 12:35:37.000000000
+0100
@@ -466,9 +466,17 @@
 			   What if we've blocked it ourselves?  What about
 			   alarms?  Why, in fact, are we mucking with the
 			   sigmask at all? -- r~ */
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+			if (current->sig->action[SIGINT - 1].sa.sa_handler == (void *)SIG_DFL)
+#else
 			if (current->sig->action[SIGINT - 1].sa.sa_handler == SIG_DFL)
+#endif
 				mask |= sigmask(SIGINT);
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+			if (current->sig->action[SIGQUIT - 1].sa.sa_handler == (void *)SIG_DFL)
+#else
 			if (current->sig->action[SIGQUIT - 1].sa.sa_handler == SIG_DFL)
+#endif
 				mask |= sigmask(SIGQUIT);
 		}
 		siginitsetinv(&current->blocked, mask);
diff -Naur linux-2.4.20-pa32/fs/proc/array.c linux-2.4.20-pa32-gcc33/fs/proc/array.c
--- linux-2.4.20-pa32/fs/proc/array.c	2003-03-21 10:01:18.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/fs/proc/array.c	2003-03-21 12:36:44.000000000
+0100
@@ -231,9 +231,17 @@
 	if (p->sig) {
 		k = p->sig->action;
 		for (i = 1; i <= _NSIG; ++i, ++k) {
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+			if (k->sa.sa_handler == (void *)SIG_IGN)
+#else
 			if (k->sa.sa_handler == SIG_IGN)
+#endif
 				sigaddset(ign, i);
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+			else if (k->sa.sa_handler != (void *)SIG_DFL)
+#else
 			else if (k->sa.sa_handler != SIG_DFL)
+#endif
 				sigaddset(catch, i);
 		}
 	}
diff -Naur linux-2.4.20-pa32/include/linux/compiler.h linux-2.4.20-pa32-gcc33/include/linux/compiler.h
--- linux-2.4.20-pa32/include/linux/compiler.h	2003-03-21 12:31:39.000000000
+0100
+++ linux-2.4.20-pa32-gcc33/include/linux/compiler.h	2003-03-21 12:32:07.000000000
+0100
@@ -1,6 +1,12 @@
 #ifndef __LINUX_COMPILER_H
 #define __LINUX_COMPILER_H
 
+#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
+#define inline		__inline__ __attribute__((always_inline))
+#define __inline__	__inline__ __attribute__((always_inline))
+#define __inline	__inline__ __attribute__((always_inline))
+#endif
+
 /* Somewhere in the middle of the GCC 2.96 development cycle, we implemented
    a mechanism by which the user can annotate likely branch directions and
    expect the blocks to be reordered appropriately.  Define __builtin_expect
diff -Naur linux-2.4.20-pa32/kernel/signal.c linux-2.4.20-pa32-gcc33/kernel/signal.c
--- linux-2.4.20-pa32/kernel/signal.c	2003-03-21 10:39:32.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/kernel/signal.c	2003-03-21 12:37:40.000000000
+0100
@@ -126,7 +126,11 @@
 	int i;
 	struct k_sigaction *ka = &t->sig->action[0];
 	for (i = _NSIG ; i != 0 ; i--) {
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+		if (ka->sa.sa_handler != (void *)SIG_IGN)
+#else
 		if (ka->sa.sa_handler != SIG_IGN)
+#endif
 			ka->sa.sa_handler = SIG_DFL;
 		ka->sa.sa_flags = 0;
 		sigemptyset(&ka->sa.sa_mask);
@@ -572,7 +576,11 @@
 		return -ESRCH;
 	}
 
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+	if (t->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN)
+#else
 	if (t->sig->action[sig-1].sa.sa_handler == SIG_IGN)
+#endif
 		t->sig->action[sig-1].sa.sa_handler = SIG_DFL;
 	sigdelset(&t->blocked, sig);
 	recalc_sigpending(t);
@@ -1094,8 +1102,13 @@
 		 * the signal to be ignored.
 		 */
 
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+		if (k->sa.sa_handler == (void *)SIG_IGN
+		    || (k->sa.sa_handler == (void *)SIG_DFL
+#else
 		if (k->sa.sa_handler == SIG_IGN
 		    || (k->sa.sa_handler == SIG_DFL
+#endif
 			&& (sig == SIGCONT ||
 			    sig == SIGCHLD ||
 			    sig == SIGURG ||
diff -Naur linux-2.4.20-pa32/net/sunrpc/clnt.c linux-2.4.20-pa32-gcc33/net/sunrpc/clnt.c
--- linux-2.4.20-pa32/net/sunrpc/clnt.c	2003-03-21 10:46:28.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/net/sunrpc/clnt.c	2003-03-21 12:38:07.000000000
+0100
@@ -209,9 +209,17 @@
 	/* Turn off various signals */
 	if (clnt->cl_intr) {
 		struct k_sigaction *action = current->sig->action;
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+		if (action[SIGINT-1].sa.sa_handler == (void *)SIG_DFL)
+#else
 		if (action[SIGINT-1].sa.sa_handler == SIG_DFL)
+#endif
 			sigallow |= sigmask(SIGINT);
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+		if (action[SIGQUIT-1].sa.sa_handler == (void *)SIG_DFL)
+#else
 		if (action[SIGQUIT-1].sa.sa_handler == SIG_DFL)
+#endif
 			sigallow |= sigmask(SIGQUIT);
 	}
 	spin_lock_irqsave(&current->sigmask_lock, irqflags);
=====

I could not be sure about __LP64__ condition because gcc-hppa62_3.3 do not
yet exist :(

Can some body else could test it more?

Joel

PS1: I hoppe it will stay just a temporary work-around; that is typical what
I hate: code depending of platform and more over compiler release :(

PS2: If I well understand the pa32 patch include the Alan patch concerning
ptrace vulnerability. Is there some simple mean to stress the solution on
hppa platform?

---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be



[-- Attachment #2: linux-2.4.20-pa32_gcc33.patch --]
[-- Type: application/octet-stream, Size: 7228 bytes --]

diff -Naur linux-2.4.20-pa32/Makefile linux-2.4.20-pa32-gcc33/Makefile
--- linux-2.4.20-pa32/Makefile	2003-03-21 12:17:41.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/Makefile	2003-03-21 12:19:06.000000000 +0100
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 4
 SUBLEVEL = 20
-EXTRAVERSION = -pa32
+EXTRAVERSION = -pa33
 
 KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
 
diff -Naur linux-2.4.20-pa32/arch/parisc/kernel/signal.c linux-2.4.20-pa32-gcc33/arch/parisc/kernel/signal.c
--- linux-2.4.20-pa32/arch/parisc/kernel/signal.c	2003-03-21 10:54:23.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/arch/parisc/kernel/signal.c	2003-03-21 12:39:20.000000000 +0100
@@ -489,7 +489,11 @@
 		ka = &current->sig->action[signr-1];
 		DBG(("sa_handler is %x\n", 
 			(unsigned int) ka->sa.sa_handler));
+#if !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+		if (ka->sa.sa_handler == (void *)SIG_IGN) {
+#else
 		if (ka->sa.sa_handler == SIG_IGN) {
+#endif
 			if (signr != SIGCHLD)
 				continue;
 			while (sys_wait4(-1, NULL, WNOHANG, NULL) > 0)
@@ -497,7 +501,11 @@
 			continue;
 		}
 
+#if !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+		if (ka->sa.sa_handler == (void *)SIG_DFL) {
+#else
 		if (ka->sa.sa_handler == SIG_DFL) {
+#endif
 			int exit_code = signr;
 
 			/* Init gets no signals it doesn't want.  */
diff -Naur linux-2.4.20-pa32/drivers/char/n_tty.c linux-2.4.20-pa32-gcc33/drivers/char/n_tty.c
--- linux-2.4.20-pa32/drivers/char/n_tty.c	2003-03-21 10:51:30.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/drivers/char/n_tty.c	2003-03-21 12:34:35.000000000 +0100
@@ -810,7 +810,11 @@
 int is_ignored(int sig)
 {
 	return (sigismember(&current->blocked, sig) ||
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+	        current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN);
+#else
 	        current->sig->action[sig-1].sa.sa_handler == SIG_IGN);
+#endif
 }
 
 static void n_tty_set_termios(struct tty_struct *tty, struct termios * old)
diff -Naur linux-2.4.20-pa32/fs/ncpfs/sock.c linux-2.4.20-pa32-gcc33/fs/ncpfs/sock.c
--- linux-2.4.20-pa32/fs/ncpfs/sock.c	2003-03-21 10:36:05.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/fs/ncpfs/sock.c	2003-03-21 12:35:37.000000000 +0100
@@ -466,9 +466,17 @@
 			   What if we've blocked it ourselves?  What about
 			   alarms?  Why, in fact, are we mucking with the
 			   sigmask at all? -- r~ */
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+			if (current->sig->action[SIGINT - 1].sa.sa_handler == (void *)SIG_DFL)
+#else
 			if (current->sig->action[SIGINT - 1].sa.sa_handler == SIG_DFL)
+#endif
 				mask |= sigmask(SIGINT);
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+			if (current->sig->action[SIGQUIT - 1].sa.sa_handler == (void *)SIG_DFL)
+#else
 			if (current->sig->action[SIGQUIT - 1].sa.sa_handler == SIG_DFL)
+#endif
 				mask |= sigmask(SIGQUIT);
 		}
 		siginitsetinv(&current->blocked, mask);
diff -Naur linux-2.4.20-pa32/fs/proc/array.c linux-2.4.20-pa32-gcc33/fs/proc/array.c
--- linux-2.4.20-pa32/fs/proc/array.c	2003-03-21 10:01:18.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/fs/proc/array.c	2003-03-21 12:36:44.000000000 +0100
@@ -231,9 +231,17 @@
 	if (p->sig) {
 		k = p->sig->action;
 		for (i = 1; i <= _NSIG; ++i, ++k) {
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+			if (k->sa.sa_handler == (void *)SIG_IGN)
+#else
 			if (k->sa.sa_handler == SIG_IGN)
+#endif
 				sigaddset(ign, i);
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+			else if (k->sa.sa_handler != (void *)SIG_DFL)
+#else
 			else if (k->sa.sa_handler != SIG_DFL)
+#endif
 				sigaddset(catch, i);
 		}
 	}
diff -Naur linux-2.4.20-pa32/include/linux/compiler.h linux-2.4.20-pa32-gcc33/include/linux/compiler.h
--- linux-2.4.20-pa32/include/linux/compiler.h	2003-03-21 12:31:39.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/include/linux/compiler.h	2003-03-21 12:32:07.000000000 +0100
@@ -1,6 +1,12 @@
 #ifndef __LINUX_COMPILER_H
 #define __LINUX_COMPILER_H
 
+#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
+#define inline		__inline__ __attribute__((always_inline))
+#define __inline__	__inline__ __attribute__((always_inline))
+#define __inline	__inline__ __attribute__((always_inline))
+#endif
+
 /* Somewhere in the middle of the GCC 2.96 development cycle, we implemented
    a mechanism by which the user can annotate likely branch directions and
    expect the blocks to be reordered appropriately.  Define __builtin_expect
diff -Naur linux-2.4.20-pa32/kernel/signal.c linux-2.4.20-pa32-gcc33/kernel/signal.c
--- linux-2.4.20-pa32/kernel/signal.c	2003-03-21 10:39:32.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/kernel/signal.c	2003-03-21 12:37:40.000000000 +0100
@@ -126,7 +126,11 @@
 	int i;
 	struct k_sigaction *ka = &t->sig->action[0];
 	for (i = _NSIG ; i != 0 ; i--) {
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+		if (ka->sa.sa_handler != (void *)SIG_IGN)
+#else
 		if (ka->sa.sa_handler != SIG_IGN)
+#endif
 			ka->sa.sa_handler = SIG_DFL;
 		ka->sa.sa_flags = 0;
 		sigemptyset(&ka->sa.sa_mask);
@@ -572,7 +576,11 @@
 		return -ESRCH;
 	}
 
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+	if (t->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN)
+#else
 	if (t->sig->action[sig-1].sa.sa_handler == SIG_IGN)
+#endif
 		t->sig->action[sig-1].sa.sa_handler = SIG_DFL;
 	sigdelset(&t->blocked, sig);
 	recalc_sigpending(t);
@@ -1094,8 +1102,13 @@
 		 * the signal to be ignored.
 		 */
 
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+		if (k->sa.sa_handler == (void *)SIG_IGN
+		    || (k->sa.sa_handler == (void *)SIG_DFL
+#else
 		if (k->sa.sa_handler == SIG_IGN
 		    || (k->sa.sa_handler == SIG_DFL
+#endif
 			&& (sig == SIGCONT ||
 			    sig == SIGCHLD ||
 			    sig == SIGURG ||
diff -Naur linux-2.4.20-pa32/net/sunrpc/clnt.c linux-2.4.20-pa32-gcc33/net/sunrpc/clnt.c
--- linux-2.4.20-pa32/net/sunrpc/clnt.c	2003-03-21 10:46:28.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/net/sunrpc/clnt.c	2003-03-21 12:38:07.000000000 +0100
@@ -209,9 +209,17 @@
 	/* Turn off various signals */
 	if (clnt->cl_intr) {
 		struct k_sigaction *action = current->sig->action;
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+		if (action[SIGINT-1].sa.sa_handler == (void *)SIG_DFL)
+#else
 		if (action[SIGINT-1].sa.sa_handler == SIG_DFL)
+#endif
 			sigallow |= sigmask(SIGINT);
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
+		if (action[SIGQUIT-1].sa.sa_handler == (void *)SIG_DFL)
+#else
 		if (action[SIGQUIT-1].sa.sa_handler == SIG_DFL)
+#endif
 			sigallow |= sigmask(SIGQUIT);
 	}
 	spin_lock_irqsave(&current->sigmask_lock, irqflags);

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Matthew Wilcox]

On Fri, Mar 21, 2003 at 01:44:28PM +0100, Joel Soete wrote:
> I test following work-around against 2.4.20-pa32 with latest dpkg gcc-3.3
> (3.3-0pre2) and it boot well know:
> @@ -489,7 +489,11 @@
> +#if !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__
> >= 1))
> +		if (ka->sa.sa_handler == (void *)SIG_IGN) {
> +#else
>  		if (ka->sa.sa_handler == SIG_IGN) {
> +#endif

ugh, this is foolish.  You should be doing:

-		if (ka->sa.sa_handler == SIG_IGN) {
+		if (ka->sa.sa_handler == (void *)SIG_IGN) {

no ifdefs!

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

>> I test following work-around against 2.4.20-pa32 with latest dpkg gcc-3.3
>> (3.3-0pre2) and it boot well know:
>> @@ -489,7 +489,11 @@
>> +#if !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__
>> >= 1))
>> +		if (ka->sa.sa_handler == (void *)SIG_IGN) {
>> +#else
>>  		if (ka->sa.sa_handler == SIG_IGN) {
>> +#endif
>
>ugh, this is foolish.  You should be doing:
>
>-		if (ka->sa.sa_handler == SIG_IGN) {
>+		if (ka->sa.sa_handler == (void *)SIG_IGN) {
>
>no ifdefs!
>
Willy, I trust you (not me because I not tested with gcc-3.2 neither LP64)

Thanks for your attention,
    Joel

PS: Next time I will try to pay attention to cc list :)

---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> >> 
> >> these are definitely kernel addresses....
> >
> >Right.  I see the code that's causing the problem in kernel/signal.c:
> >
> >                if (k->sa.sa_handler == SIG_IGN
> >		    || (k->sa.sa_handler == SIG_DFL
> >
> >
> >You don't want to canonicalize k->sa.sa_handler here, so a cast to
> >void * or something is needed.  The PA is the only port that I am
> >aware of that needs to canonicalize function pointers.
> >
> Well I try to test some:
> --- signal.h.orig       2003-03-20 15:12:24.000000000 +0100
> +++ signal.h    2003-03-20 15:11:47.000000000 +0100
> @@ -106,9 +106,15 @@
>  #define SIG_UNBLOCK        1   /* for unblocking signals */
>  #define SIG_SETMASK        2   /* for setting the signal mask */
>  
> +#if __GNUC__ == 3 && __GNUC_MINOR__ >= 3 || __GNUC__ > 3
> +#define SIG_DFL        (0)                     /* default signal handling
> */
> +#define SIG_IGN        (1)                     /* ignore signal */
> +#define SIG_ERR        (-1)                    /* error return from signal
> */
> +#else
>  #define SIG_DFL        ((__sighandler_t)0)     /* default signal handling
> */
>  #define SIG_IGN        ((__sighandler_t)1)     /* ignore signal */
>  #define SIG_ERR        ((__sighandler_t)-1)    /* error return from signal
> */
> +#endif

No, don't do that.  SIG_DFL, SIG_IGN and SIG_ERR expand to compound
literals.  Look at the assembly output from the following little
program (gcc -S) with and without the "void *" cast.

typedef int (*__sighandler_t)(void);
#define SIG_IGN        ((__sighandler_t)1)
int foo (__sighandler_t g)
{
  return g == (void *)SIG_IGN;
}

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

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Randolph Chung]

> I believe that we were talking about a problem in in glibc's use
> of __canonicalize_funcptr_for_compare with a gcc 3.3 compiled kernel.

Quoting an earlier mail:
> IAOQ = 10351b7c
> Func: __canonicalize_funcptr_for_compare, Off: 38, Addr: 0x10351b7c
> 10351b70:       2a 6b 50 00     addil 56800,r19,%r1
> 10351b74:       48 21 0c a8     ldw 654(r1),r1
> 10351b78:       d4 60 1c 1e     depwi 0,31,2,r3
> 10351b7c:       0c 60 10 94     ldw 0(sr0,r3),r20
>
> GR0 = 00000000
>
> GR1 = 103eee50
> Func: _GLOBAL_OFFSET_TABLE_, Off: 0, Addr: 0x103eee50
>
> GR2 = 101342f8
> Func: do_sigaction, Off: a8, Addr: 0x101342f8

these are definitely kernel addresses....

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Randolph Chung]

> __canonicalize_funcptr_for_compare depends critically on the
> the initial setup of function descriptors by the dynamic loader
> and the trampoline in the dynamic loader used to resolve the
> address of functions.  This could easily break if someone
> unknowing messes with the pa specific parts of the dynamic
> loader or the setup of function descriptors.

um, Dave, we are talking about kernel here right? so no dynamic loader
is involved.

or did i misnuderstand you?
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> I'm building glibc-2.3.1-15 and should know soon if something
> has changed.

The enclosed patch to pt-initfini.c for gcc 3.3 is missing from -15.

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

--- pt-initfini.c.orig	2002-08-26 21:52:36.000000000 -0700
+++ pt-initfini.c	2003-03-18 12:11:20.000000000 -0800
@@ -41,70 +41,70 @@
    and epilogues.  Therefore we write these in assembly to make sure
    they do the right thing.  */
 
-__asm__ ("
-
-#include \"defs.h\"
-
-/*@HEADER_ENDS*/
-
-/*@_init_PROLOG_BEGINS*/
-	.section .init
-	.align 4
-	.globl _init
-	.type _init,@function
-_init:
-	stw	%rp,-20(%sp)
-	stwm	%r4,64(%sp)
-	stw	%r19,-32(%sp)
-	bl	__pthread_initialize_minimal,%rp
-	copy	%r19,%r4	/* delay slot */
-	copy	%r4,%r19
-/*@_init_PROLOG_ENDS*/
-
-/*@_init_EPILOG_BEGINS*/
-/* Here is the tail end of _init.  */
-	.section .init
-	ldw	-84(%sp),%rp
-	copy	%r4,%r19
-	bv	%r0(%rp)
-_end_init:
-	ldwm	-64(%sp),%r4
-
-/* Our very own unwind info, because the assembler can't handle
-   functions split into two or more pieces.  */
-	.section .PARISC.unwind,\"a\",@progbits
-	.extern _init
-	.word	_init, _end_init
-	.byte	0x08, 0x01, 0x00, 0x08, 0x00, 0x00, 0x00, 0x08
-
-/*@_init_EPILOG_ENDS*/
-
-/*@_fini_PROLOG_BEGINS*/
-	.section .fini
-	.align 4
-	.globl _fini
-	.type _fini,@function
-_fini:
-	stw	%rp,-20(%sp)
-	stwm	%r4,64(%sp)
-	stw	%r19,-32(%sp)
-	copy	%r19,%r4
-/*@_fini_PROLOG_ENDS*/
-
-/*@_fini_EPILOG_BEGINS*/
-	.section .fini
-	ldw	-84(%sp),%rp
-	copy	%r4,%r19
-	bv	%r0(%rp)
-_end_fini:
-	ldwm	-64(%sp),%r4
-
-	.section .PARISC.unwind,\"a\",@progbits
-	.extern _fini
-	.word	_fini, _end_fini
-	.byte	0x08, 0x01, 0x00, 0x08, 0x00, 0x00, 0x00, 0x08
-
-/*@_fini_EPILOG_ENDS*/
-
-/*@TRAILER_BEGINS*/
+__asm__ ("								\n\
+									\n\
+#include \"defs.h\"							\n\
+									\n\
+/*@HEADER_ENDS*/							\n\
+									\n\
+/*@_init_PROLOG_BEGINS*/						\n\
+	.section .init							\n\
+	.align 4							\n\
+	.globl _init							\n\
+	.type _init,@function						\n\
+_init:									\n\
+	stw	%rp,-20(%sp)						\n\
+	stwm	%r4,64(%sp)						\n\
+	stw	%r19,-32(%sp)						\n\
+	bl	__pthread_initialize_minimal,%rp			\n\
+	copy	%r19,%r4	/* delay slot */			\n\
+	copy	%r4,%r19						\n\
+/*@_init_PROLOG_ENDS*/							\n\
+									\n\
+/*@_init_EPILOG_BEGINS*/						\n\
+/* Here is the tail end of _init.  */					\n\
+	.section .init							\n\
+	ldw	-84(%sp),%rp						\n\
+	copy	%r4,%r19						\n\
+	bv	%r0(%rp)						\n\
+_end_init:								\n\
+	ldwm	-64(%sp),%r4						\n\
+									\n\
+/* Our very own unwind info, because the assembler can't handle		\n\
+   functions split into two or more pieces.  */				\n\
+	.section .PARISC.unwind,\"a\",@progbits				\n\
+	.extern _init							\n\
+	.word	_init, _end_init					\n\
+	.byte	0x08, 0x01, 0x00, 0x08, 0x00, 0x00, 0x00, 0x08		\n\
+									\n\
+/*@_init_EPILOG_ENDS*/							\n\
+									\n\
+/*@_fini_PROLOG_BEGINS*/						\n\
+	.section .fini							\n\
+	.align 4							\n\
+	.globl _fini							\n\
+	.type _fini,@function						\n\
+_fini:									\n\
+	stw	%rp,-20(%sp)						\n\
+	stwm	%r4,64(%sp)						\n\
+	stw	%r19,-32(%sp)						\n\
+	copy	%r19,%r4						\n\
+/*@_fini_PROLOG_ENDS*/							\n\
+									\n\
+/*@_fini_EPILOG_BEGINS*/						\n\
+	.section .fini							\n\
+	ldw	-84(%sp),%rp						\n\
+	copy	%r4,%r19						\n\
+	bv	%r0(%rp)						\n\
+_end_fini:								\n\
+	ldwm	-64(%sp),%r4						\n\
+									\n\
+	.section .PARISC.unwind,\"a\",@progbits				\n\
+	.extern _fini							\n\
+	.word	_fini, _end_fini					\n\
+	.byte	0x08, 0x01, 0x00, 0x08, 0x00, 0x00, 0x00, 0x08		\n\
+									\n\
+/*@_fini_EPILOG_ENDS*/							\n\
+									\n\
+/*@TRAILER_BEGINS*/							\n\
 ");

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> I'm building glibc-2.3.1-15 and should know soon if something
> has changed.

The enclosed patch to pt-initfini.c for gcc 3.3 is missing from -15.

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

--- pt-initfini.c.orig	2002-08-26 21:52:36.000000000 -0700
+++ pt-initfini.c	2003-03-18 12:11:20.000000000 -0800
@@ -41,70 +41,70 @@
    and epilogues.  Therefore we write these in assembly to make sure
    they do the right thing.  */
 
-__asm__ ("
-
-#include \"defs.h\"
-
-/*@HEADER_ENDS*/
-
-/*@_init_PROLOG_BEGINS*/
-	.section .init
-	.align 4
-	.globl _init
-	.type _init,@function
-_init:
-	stw	%rp,-20(%sp)
-	stwm	%r4,64(%sp)
-	stw	%r19,-32(%sp)
-	bl	__pthread_initialize_minimal,%rp
-	copy	%r19,%r4	/* delay slot */
-	copy	%r4,%r19
-/*@_init_PROLOG_ENDS*/
-
-/*@_init_EPILOG_BEGINS*/
-/* Here is the tail end of _init.  */
-	.section .init
-	ldw	-84(%sp),%rp
-	copy	%r4,%r19
-	bv	%r0(%rp)
-_end_init:
-	ldwm	-64(%sp),%r4
-
-/* Our very own unwind info, because the assembler can't handle
-   functions split into two or more pieces.  */
-	.section .PARISC.unwind,\"a\",@progbits
-	.extern _init
-	.word	_init, _end_init
-	.byte	0x08, 0x01, 0x00, 0x08, 0x00, 0x00, 0x00, 0x08
-
-/*@_init_EPILOG_ENDS*/
-
-/*@_fini_PROLOG_BEGINS*/
-	.section .fini
-	.align 4
-	.globl _fini
-	.type _fini,@function
-_fini:
-	stw	%rp,-20(%sp)
-	stwm	%r4,64(%sp)
-	stw	%r19,-32(%sp)
-	copy	%r19,%r4
-/*@_fini_PROLOG_ENDS*/
-
-/*@_fini_EPILOG_BEGINS*/
-	.section .fini
-	ldw	-84(%sp),%rp
-	copy	%r4,%r19
-	bv	%r0(%rp)
-_end_fini:
-	ldwm	-64(%sp),%r4
-
-	.section .PARISC.unwind,\"a\",@progbits
-	.extern _fini
-	.word	_fini, _end_fini
-	.byte	0x08, 0x01, 0x00, 0x08, 0x00, 0x00, 0x00, 0x08
-
-/*@_fini_EPILOG_ENDS*/
-
-/*@TRAILER_BEGINS*/
+__asm__ ("								\n\
+									\n\
+#include \"defs.h\"							\n\
+									\n\
+/*@HEADER_ENDS*/							\n\
+									\n\
+/*@_init_PROLOG_BEGINS*/						\n\
+	.section .init							\n\
+	.align 4							\n\
+	.globl _init							\n\
+	.type _init,@function						\n\
+_init:									\n\
+	stw	%rp,-20(%sp)						\n\
+	stwm	%r4,64(%sp)						\n\
+	stw	%r19,-32(%sp)						\n\
+	bl	__pthread_initialize_minimal,%rp			\n\
+	copy	%r19,%r4	/* delay slot */			\n\
+	copy	%r4,%r19						\n\
+/*@_init_PROLOG_ENDS*/							\n\
+									\n\
+/*@_init_EPILOG_BEGINS*/						\n\
+/* Here is the tail end of _init.  */					\n\
+	.section .init							\n\
+	ldw	-84(%sp),%rp						\n\
+	copy	%r4,%r19						\n\
+	bv	%r0(%rp)						\n\
+_end_init:								\n\
+	ldwm	-64(%sp),%r4						\n\
+									\n\
+/* Our very own unwind info, because the assembler can't handle		\n\
+   functions split into two or more pieces.  */				\n\
+	.section .PARISC.unwind,\"a\",@progbits				\n\
+	.extern _init							\n\
+	.word	_init, _end_init					\n\
+	.byte	0x08, 0x01, 0x00, 0x08, 0x00, 0x00, 0x00, 0x08		\n\
+									\n\
+/*@_init_EPILOG_ENDS*/							\n\
+									\n\
+/*@_fini_PROLOG_BEGINS*/						\n\
+	.section .fini							\n\
+	.align 4							\n\
+	.globl _fini							\n\
+	.type _fini,@function						\n\
+_fini:									\n\
+	stw	%rp,-20(%sp)						\n\
+	stwm	%r4,64(%sp)						\n\
+	stw	%r19,-32(%sp)						\n\
+	copy	%r19,%r4						\n\
+/*@_fini_PROLOG_ENDS*/							\n\
+									\n\
+/*@_fini_EPILOG_BEGINS*/						\n\
+	.section .fini							\n\
+	ldw	-84(%sp),%rp						\n\
+	copy	%r4,%r19						\n\
+	bv	%r0(%rp)						\n\
+_end_fini:								\n\
+	ldwm	-64(%sp),%r4						\n\
+									\n\
+	.section .PARISC.unwind,\"a\",@progbits				\n\
+	.extern _fini							\n\
+	.word	_fini, _end_fini					\n\
+	.byte	0x08, 0x01, 0x00, 0x08, 0x00, 0x00, 0x00, 0x08		\n\
+									\n\
+/*@_fini_EPILOG_ENDS*/							\n\
+									\n\
+/*@TRAILER_BEGINS*/							\n\
 ");

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[b.gunreben]

Joel Soete wrote:
> >gcc 3.3 decides to not believe you want this function inlined.  probably
> >the right fix for this is to make this function static inline (you can
> >drop the `__' around inline, it's not necessary).  This is also the case
> >for linux 2.5.
> >
> Right Willy that allow to compile :)
> 
> Unfortunately it failled to boot :_( with following dump:
> Freeing unused kernel memory: 246k freed
> ......
> Submitted to dump_analyser.sh, I obtain:
> 
> IAOQ = 10351b7c
> Func: __canonicalize_funcptr_for_compare, Off: 38, Addr: 0x10351b7c
> 10351b70:       2a 6b 50 00     addil 56800,r19,%r1
> 10351b74:       48 21 0c a8     ldw 654(r1),r1
> 10351b78:       d4 60 1c 1e     depwi 0,31,2,r3
> 10351b7c:       0c 60 10 94     ldw 0(sr0,r3),r20
> 
> GR0 = 00000000
> 
> GR1 = 103eee50
> Func: _GLOBAL_OFFSET_TABLE_, Off: 0, Addr: 0x103eee50
> 
> GR2 = 101342f8
> Func: do_sigaction, Off: a8, Addr: 0x101342f8

I have the same problem with a gcc 3.3 compiled kernel. The kernel itself
completely comes up, and I even can call a static shell (something like
init=/bin/sash), but as soon as glibc is involved, the mentioned crash
occurs. Just to make it clear: I am able to use the builtin functions of
that shell (like ls) and this works.

This is independend from the kernel version (2.4 and 2.5 behave all the
same). The function __canonicalize_funcptr_for_compare seems to be newly
introduced in libgcc with gcc 3.3, and seems to be the cause of this error.


Berthold

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Michael S.Zick]

On Friday 14 March 2003 07:17 am, Matthew Wilcox wrote:
> On Fri, Mar 14, 2003 at 01:48:59PM +0100, Joel Soete wrote:
> > net/network.o(.text.rtnetlink_rcv+0x84): In function `rtnetlink_rcv':
> > : undefined reference to `rtnetlink_rcv_skb'
> >
> > make: *** [vmlinux] Error 1
> >
> > (with gcc-3.2 with same src && same .config there was no pb)
>
> You've just hit the gcc thinks it's smarter than you are bug.
>
> net/core/rtnetlink.c:extern __inline__ int rtnetlink_rcv_skb(struct sk_buff
> *skb)
>
> gcc 3.3 decides to not believe you want this function inlined.  probably
> the right fix for this is to make this function static inline (you can
> drop the `__' around inline, it's not necessary).  This is also the case
> for linux 2.5.

Stolen from the GCC thread on 3.x.x inlining...
- - - - GCC - - - - -
For the record, the kernel doesn't need this any more.  Go check 2.5;
new versions of <linux/compiler.h> contain this line:
#define inline          __inline__ __attribute__((always_inline))
- - - - - - - - - - - -
That forces GCC to ignore its changed inline metrics and simply inline
the function.

Mike

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Matthew Wilcox]

On Sun, Mar 16, 2003 at 04:52:19PM -0600, Michael S. Zick wrote:
> On Friday 14 March 2003 07:17 am, Matthew Wilcox wrote:
> > net/core/rtnetlink.c:extern __inline__ int rtnetlink_rcv_skb(struct sk_buff
> > *skb)
> Stolen from the GCC thread on 3.x.x inlining...
> - - - - GCC - - - - -
> For the record, the kernel doesn't need this any more.  Go check 2.5;
> new versions of <linux/compiler.h> contain this line:
> #define inline          __inline__ __attribute__((always_inline))
> - - - - - - - - - - - -
> That forces GCC to ignore its changed inline metrics and simply inline
> the function.

Yes, but...

 * Joel's using 2.4, not 2.5
 * #define inline doesn't help functions which are marked as __inline__

This isn't a function which absolutely needs to be inlined.  It can
be `static inline' and gcc can do whatever it likes then.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Michael S.Zick]

On Sunday 16 March 2003 05:06 pm, Matthew Wilcox wrote:
> On Sun, Mar 16, 2003 at 04:52:19PM -0600, Michael S. Zick wrote:
> > On Friday 14 March 2003 07:17 am, Matthew Wilcox wrote:
> > > net/core/rtnetlink.c:extern __inline__ int rtnetlink_rcv_skb(struct
> > > sk_buff *skb)
> >
> > Stolen from the GCC thread on 3.x.x inlining...
> > - - - - GCC - - - - -
> > For the record, the kernel doesn't need this any more.  Go check 2.5;
> > new versions of <linux/compiler.h> contain this line:
> > #define inline          __inline__ __attribute__((always_inline))
> > - - - - - - - - - - - -
> > That forces GCC to ignore its changed inline metrics and simply inline
> > the function.
>
> Yes, but...
>
>  * Joel's using 2.4, not 2.5
Exactly why I mentioned it.

>  * #define inline doesn't help functions which are marked as __inline__
If he follows your suggestion of dropping the "__" around "inline" it will.

>
> This isn't a function which absolutely needs to be inlined.  It can
> be `static inline' and gcc can do whatever it likes then.
The subject is getting a lot of discussion on the GCC list.  I only mentioned
this one workaround so that Joel could get on with his work before the issue
is settled on the GCC list.

Mike

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

Hi Mike,

>On Sunday 16 March 2003 05:06 pm, Matthew Wilcox wrote:
>> On Sun, Mar 16, 2003 at 04:52:19PM -0600, Michael S. Zick wrote:
>> > On Friday 14 March 2003 07:17 am, Matthew Wilcox wrote:
>> > > net/core/rtnetlink.c:extern __inline__ int rtnetlink_rcv_skb(struct
>> > > sk_buff *skb)
>> >
>> > Stolen from the GCC thread on 3.x.x inlining...
>> > - - - - GCC - - - - -
>> > For the record, the kernel doesn't need this any more.  Go check 2.5;
>> > new versions of <linux/compiler.h> contain this line:
>> > #define inline          __inline__ __attribute__((always_inline))
>> > - - - - - - - - - - - -
>> > That forces GCC to ignore its changed inline metrics and simply inline
>> > the function.
>>
>> Yes, but...
>>
>>  * Joel's using 2.4, not 2.5
>Exactly why I mentioned it.
>
>>  * #define inline doesn't help functions which are marked as __inline__
>If he follows your suggestion of dropping the "__" around "inline" it will.
>
>>
>> This isn't a function which absolutely needs to be inlined.  It can
>> be `static inline' and gcc can do whatever it likes then.
>The subject is getting a lot of discussion on the GCC list.  I only mentioned
>this one workaround so that Joel could get on with his work before the issue
>is settled on the GCC list.
>
Good idea: I (just sorry for delay) back port this stuff for 2.5 and it works
fine.

Thanks a lot,
    Joel


---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Matthew Wilcox]

On Fri, Mar 14, 2003 at 01:48:59PM +0100, Joel Soete wrote:
> net/network.o(.text.rtnetlink_rcv+0x84): In function `rtnetlink_rcv':
> : undefined reference to `rtnetlink_rcv_skb'
> make: *** [vmlinux] Error 1
> 
> (with gcc-3.2 with same src && same .config there was no pb)

You've just hit the gcc thinks it's smarter than you are bug.

net/core/rtnetlink.c:extern __inline__ int rtnetlink_rcv_skb(struct sk_buff *skb)

gcc 3.3 decides to not believe you want this function inlined.  probably
the right fix for this is to make this function static inline (you can
drop the `__' around inline, it's not necessary).  This is also the case
for linux 2.5.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

Hi Randolph,

>>
>>> I am looking to rebuild gcc-3.3 64bits to rebuild the last kernel 2.4
>to
>>> conitnue my investigation about smp(64bits) [which failled to boot on
>a
>>N4000
>>> when compile d with gcc-3.2 get from unofficial-debs].
>>
>>If you are working on 64-bit, I would advise staying with 3.0.4 for
>>now.... no one has tested 3.3 hppa64-linux-gcc at all, so it will just
>>be introducing more unknowns into the problem.
>>
>Ok I am gonna try to rebuild it with gcc-3.0.
>
Well just a small follow up to say that I had not much success with gcc-3.0
(64bits).

Also I did some other test:
this same kernel (smp64) boots well on a b2k (pa8600 up),
it boots also well on the N4000 when I 'disable' the second cpu?

(It seems to fail before 'Add swap...' but not sure because I notice that
all boot blabla is not output to the console [ie compare to dmesg nothing
is print out before 'sym53c8xx: at PCI...']?)

I will so try to ack dump_analyser to see how may I got analyse of the piminfo
which I grab from the two processor.

See you,
    Joel


---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

Hi Randolph,

>>
>>> I am looking to rebuild gcc-3.3 64bits to rebuild the last kernel 2.4
>to
>>> conitnue my investigation about smp(64bits) [which failled to boot on
>a
>>N4000
>>> when compile d with gcc-3.2 get from unofficial-debs].
>>
>>If you are working on 64-bit, I would advise staying with 3.0.4 for
>>now.... no one has tested 3.3 hppa64-linux-gcc at all, so it will just
>>be introducing more unknowns into the problem.
>>
>Ok I am gonna try to rebuild it with gcc-3.0.
>
Well just a small follow up to say that I had not much success with gcc-3.0
(64bits).

Also I did some other test:
this same kernel (smp64) boots well on a b2k (pa8600 up),
it boots also well on the N4000 when I 'disable' the second cpu?

(It seems to fail before 'Add swap...' but not sure because I notice that
all boot blabla is not output to the console [ie compare to dmesg nothing
is print out before 'sym53c8xx: at PCI...']?)

I will so try to ack dump_analyser to see how may I got analyse of the piminfo
which I grab from the two processor.

See you,
    Joel


---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

>-- Original Message --
>Date: Wed, 12 Mar 2003 09:35:05 -0800
>From: Randolph Chung <tausq@debian.org>
>To: Joel Soete <jsoe0708@tiscali.be>
>Cc: Matthias Klose <doko@cs.tu-berlin.de>,
>	debian-hppa@lists.debian.org, debian-gcc@lists.debian.org,
>	parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa
>Reply-To: Randolph Chung <tausq@debian.org>
>
>
>> I am looking to rebuild gcc-3.3 64bits to rebuild the last kernel 2.4
to
>> conitnue my investigation about smp(64bits) [which failled to boot on
a
>N4000
>> when compile d with gcc-3.2 get from unofficial-debs].
>
>If you are working on 64-bit, I would advise staying with 3.0.4 for
>now.... no one has tested 3.3 hppa64-linux-gcc at all, so it will just
>be introducing more unknowns into the problem.
>
Ok I am gonna try to rebuild it with gcc-3.0.

Thanks for advise,
    Joel

---------------------------------
Vous surfez avec une ligne classique ?
Faites des economies avec Tiscali Complete
... Plus d'info sur http://complete.tiscali.be

RE: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[Joel Soete]

Hi Randolph,

>-- Original Message --
>From: Randolph Chung <tausq@debian.org>
>To: Matthias Klose <doko@cs.tu-berlin.de>
>Cc: debian-hppa@lists.debian.org, debian-gcc@lists.debian.org,
>	parisc-linux@lists.parisc-linux.org
>Reply-To: Randolph Chung <tausq@debian.org>
>Subject: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa
>Date: Sat, 1 Mar 2003 20:59:36 -0800
>
>
>In reference to a message from Matthias Klose, dated Mar 01:
>> Matthias Klose writes:
>> > AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
>> > code due to the changed exception handling (now DWARF2 based). As
>> > libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?
>> > Currently 3.2 is in unstable only. Would you want to start the
>> > recompilation before 3.2 based binaries go to testing?
>> > 
>> > The packaging for 3.3 can be found in the Debian CVS.
>> 
>> You can get test packages from
>> 	http://ftp-master.debian.org/~doko/gcc-3.3/
>
>well.... this is not looking good. after installing these in a freshly
>built sarge chroot, all c++ programs stop working (well, i've only tried
>two -- apt and fakeroot)
>
>(btw, small packaging detail, but the libstdc++*-dev package above
>cannot be installed cleanly because it overwrites things in the current
>3.2 package)
>

Sorry in advance if I am annoying.

I am looking to rebuild gcc-3.3 64bits to rebuild the last kernel 2.4 to
conitnue my investigation about smp(64bits) [which failled to boot on a N4000
when compile d with gcc-3.2 get from unofficial-debs].

To do I download the very last src from Matthias Klose who advise me to my
question:
>> Do you have some idea how to rebuild it from dpkg sources?
>> (I would like avoid the toolchain procedure if possible)

>look at debian/rules.defs for the support to build a cross compiler.
>It was submitted some weeks ago. I didn't check this myself yet.

I have a look but it is not clear to me; can you help me in more details?
(ps: I already install the last Matthias gcc-3.3 dpkg 32bits;
according to your <http://lists.parisc-linux.org/pipermail/parisc-linux/2003-February/019170.html>
it is a prerequisite)

Thanks in advance,
    Joel


---------------------------------
Vous surfez avec une ligne classique ?
Faites des economies avec Tiscali Complete
... Plus d'info sur http://complete.tiscali.be