Re: the mangling of ‘va_list’ has changed in GCC 4.4
On Wed, Jan 27, 2010 at 11:11 PM, Riku Voipio wrote: > Interesting. Do you have a example on howto do that? http://git.debian.org/?p=pkg-kde/qt4-x11.git;a=blob;f=debian/patches/92_armel_gcc43_valist_compat.diff;h=1db7aa33b73193a8ac0ff563f7a81bff40bfab61;hb=b3e8073df9201386aa420d5f4cab839615a0c6c5 cheers, Fathi -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: the mangling of ‘va_list’ has changed in GCC 4.4
Hello,
On ketvirtadienis 28 Sausis 2010 10:23:20 Fathi Boudra wrote:
> On Wed, Jan 27, 2010 at 11:11 PM, Riku Voipio wrote:
> > Interesting. Do you have a example on howto do that?
>
> http://git.debian.org/?p=pkg-kde/qt4-x11.git;a=blob;f=debian/patches/92_arm
> el_gcc43_valist_compat.diff;h=1db7aa33b73193a8ac0ff563f7a81bff40bfab61;hb=b
> 3e8073df9201386aa420d5f4cab839615a0c6c5
I have recently came across .symver directive [1][2] that is more
straightforward way to achieve the same thing. In that case, only source file
(.cpp) needs to be changed. For example:
---
$ cat test.h
void myprint(const char* fmt, va_list list);
$ cat libtest.cpp
#include
#include "test.h"
void myprint(const char* fmt, va_list list) {
}
// va_list mangling has been changed in g++ 4.4
// Add ABI <= g++-4.3 compatibility hack
#if defined __ARM_EABI__ && defined __GNUC__ && (__GNUC__ > 4 || __GNUC__ == 4
&& __GNUC_MINOR__ >= 4)
__asm__(".symver _Z7myprintPKcSt9__va_list, _Z7myprintPKcPv@@");
#endif
---
"_Z7myprintPKcSt9__va_list" ( myprint(char const*, std::__va_list) )
here is the new mangling while "_Z7myprintPKcPv ( myprint(char const*, void*)
)" is the old mangling. When this code is built under g++-4.4, the resulting
binary will have both symbols with _Z7myprintPKcPv and
'_Z7myprintPKcSt9__va_list' referring to the same address:
$ objdump -T libtest.so | grep _Z7myprint
06d8 gDF .text 0058 Base_Z7myprintPKcSt9__va_list
06d8 gDF .text 0058 Base_Z7myprintPKcPv
1. http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gnu-
assembler/symver.html
2. http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-
linker/version.html
--
Modestas Vainius
signature.asc
Description: This is a digitally signed message part.
Re: the mangling of ‘va_lis t’ has changed in GCC 4.4
* Matthias Klose , 2010-01-27, 23:25: IMO the major work is to identify affected libraries. if this is done, you can decide if binNMUs or manual creation of aliases is the bigger pain. On some other architectures (like amd64) std::va_list is already mangled to something easily greppable. This is how (more or less) I made my list of affected packages. -- Jakub Wilk signature.asc Description: Digital signature
Processed: Block
Processing commands for cont...@bugs.debian.org: > block 373253 by 567182 Bug #373253 [debian-installer] "libgcc_s.so.1 on AMD64 and PowerPC should be provided Was not blocked by any bugs. Added blocking bug(s) of 373253: 567182 > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[Bug c++/42713] [4.5 Regression] ICE - segfault in tsubst
--- Comment #6 from dodji at gcc dot gnu dot org 2010-01-28 12:30 --- Subject: Bug 42713 Author: dodji Date: Thu Jan 28 12:29:52 2010 New Revision: 156316 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156316 Log: Fix PR c++/42713 gcc/cp/ChangeLog: PR c++/42713 PR c++/42820 * typeck.c (get_template_parms_of_dependent_type): Factorized this out of incompatible_template_type_parms_p (incompatible_dependent_types_p): Renamed incompatible_template_type_parms_p into this. Make it detect two incompatible dependent typedefs too. (structural_comptypes): Use incompatible_dependent_types_p. * pt.c (get_template_info): Handle BOUND_TEMPLATE_TEMPLATE_PARAM. gcc/testsuite/ChangeLog: PR c++/42713 PR c++/42820 * g++.dg/template/typedef27.C: New test case. * g++.dg/template/typedef28.C: New test case. Added: trunk/gcc/testsuite/g++.dg/template/typedef27.C trunk/gcc/testsuite/g++.dg/template/typedef28.C trunk/gcc/testsuite/g++.dg/template/typedef29.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42713 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567182: gcc: Please add libgcc1-udeb for Debian Installer
On 27.01.2010 23:26, Frans Pop wrote: Thanks a lot for the quick reply. On Wednesday 27 January 2010, Matthias Klose wrote: The patch itself looks ok, some other questions: - did you consider building the udeb from a separate source package, build-depending on gcc-4.4-source? No, I had not considered that. It's an option that has both advantages and disadvantages. The main disadvantage IIUC would be that we'd have to upload or binNMU that separate package every time gcc gets uploaded (for source compliance), which means it needs special tracking. I think for that reason it's a solution the Release team is generally not all that happy with. no, that's wrong. this is only required if the upstream tarball changes, and this is easily discovered by looking at the build dependencies. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[Bug c++/42820] [4.5 Regression] ICE in tree-check, accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9868
--- Comment #4 from dodji at gcc dot gnu dot org 2010-01-28 12:30 --- Subject: Bug 42820 Author: dodji Date: Thu Jan 28 12:29:52 2010 New Revision: 156316 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156316 Log: Fix PR c++/42713 gcc/cp/ChangeLog: PR c++/42713 PR c++/42820 * typeck.c (get_template_parms_of_dependent_type): Factorized this out of incompatible_template_type_parms_p (incompatible_dependent_types_p): Renamed incompatible_template_type_parms_p into this. Make it detect two incompatible dependent typedefs too. (structural_comptypes): Use incompatible_dependent_types_p. * pt.c (get_template_info): Handle BOUND_TEMPLATE_TEMPLATE_PARAM. gcc/testsuite/ChangeLog: PR c++/42713 PR c++/42820 * g++.dg/template/typedef27.C: New test case. * g++.dg/template/typedef28.C: New test case. Added: trunk/gcc/testsuite/g++.dg/template/typedef27.C trunk/gcc/testsuite/g++.dg/template/typedef28.C trunk/gcc/testsuite/g++.dg/template/typedef29.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42820 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[Bug c++/42713] [4.5 Regression] ICE - segfault in tsubst
--- Comment #7 from dodji at gcc dot gnu dot org 2010-01-28 12:30 --- Fixed in trunk. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42713 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: the mangling of ‘va_list’ has changed in GCC 4.4
On Wednesday 27 January 2010, Bastian Blank wrote: > On Wed, Jan 27, 2010 at 10:47:55PM +0200, Riku Voipio wrote: > > There is a major problem with gcc 4.4 and armel - the ABI of va_list > > changed (for c++ libraries). We need to decide one of the following: > > What exactly have changed? The ABI (as said in the sentence before) or > the mangling. Just the mangling. > 4) If it is only the mangling, add a compatibility symbol to libstdc++. libstdc++ never uses std::va_list in a piblic interface, so is not effected. The problem exists in other libraries which do use std::va_list in their public interfaces. Paul -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567182: gcc: Please add libgcc1-udeb for Debian Installer
On Thursday 28 January 2010, Matthias Klose wrote: > On 27.01.2010 23:26, Frans Pop wrote: > > On Wednesday 27 January 2010, Matthias Klose wrote: > >>- did you consider building the udeb from a separate source > >> package, build-depending on gcc-4.4-source? > > > > No, I had not considered that. It's an option that has both advantages > > and disadvantages. > > > > The main disadvantage IIUC would be that we'd have to upload or binNMU > > that separate package every time gcc gets uploaded (for source > > compliance), which means it needs special tracking. I think for that > > reason it's a solution the Release team is generally not all that > > happy with. > > no, that's wrong. this is only required if the upstream tarball changes, > and this is easily discovered by looking at the build dependencies. Right. That reduces the problem a bit. It would mean that migrations of gcc could be blocked until a new "gcc-udeb" source package is uploaded. That would not be the case if the udebs are built from gcc. I'm still not convinced that the (IMO minor) disadvantages of having a udeb in gcc are sufficient to treat gcc different from all other packages that provide udebs. I would appreciate input from the Release team on this. Could someone please comment? See http://bugs.debian.org/567182#10 and later for most relevant info. Comments from others in the D-I team would also be welcome. Cheers, FJP -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#566514: gcc-defaults makes java-gcj-compat-headless uninstallable
Processing commands for cont...@bugs.debian.org: > reassign 566514 java-gcj-compat Bug #566514 [gcj-jre-headless] gcc-defaults makes java-gcj-compat-headless uninstallable Bug reassigned from package 'gcj-jre-headless' to 'java-gcj-compat'. Bug No longer marked as found in versions gcc-defaults/1.92. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#221291: board ed fligh tily desic cated empyr ean sicki shly
sapwo od align ing belly achin g subdi stric t demag netiz es previ siona ry infor mal venom isati on terro riser bicyc led herdl ike ridic ulous ly mynah mynah mouse trap adjus ting frate rnity mailc oach digit izing stann aries daiqu iris congr egate s jowl tande mise natur alize rs marke d cygne t alacr ity chirr up sulph ite multi subje ct greet voida ble super egos domin ates stout er fumar ate -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[Bug libstdc++/42460] man page errors for generated libstdc++ man pages
-- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: the mangling of ‘va_list’ has ch anged in GCC 4.4
Modestas Vainius wrote:
I have recently came across .symver directive [1][2] that is more
straightforward way to achieve the same thing. In that case, only source file
(.cpp) needs to be changed.
Brilliant! This shall be the plan then:
1) identify affected libraries (Jakubs list as base?)
2) provide patches for the libraries and submit them to BTS
3) give maintainers X days to MU the libraries, after that proceed to
NMU them
4) binNMU any packages using the functions with va_list parameters
5) release squeeze ;)
6) tell maintainers they are free to drop the symbol alias
Sounds ok to everyone?
For example:
---
$ cat test.h
void myprint(const char* fmt, va_list list);
$ cat libtest.cpp
#include
#include "test.h"
void myprint(const char* fmt, va_list list) {
}
// va_list mangling has been changed in g++ 4.4
// Add ABI <= g++-4.3 compatibility hack
#if defined __ARM_EABI__ && defined __GNUC__ && (__GNUC__ > 4 || __GNUC__ == 4
&& __GNUC_MINOR__ >= 4)
__asm__(".symver _Z7myprintPKcSt9__va_list, _Z7myprintPKcPv@@");
#endif
---
"_Z7myprintPKcSt9__va_list" ( myprint(char const*, std::__va_list) )
here is the new mangling while "_Z7myprintPKcPv ( myprint(char const*, void*)
)" is the old mangling. When this code is built under g++-4.4, the resulting
binary will have both symbols with _Z7myprintPKcPv and
'_Z7myprintPKcSt9__va_list' referring to the same address:
$ objdump -T libtest.so | grep _Z7myprint
06d8 gDF .text 0058 Base_Z7myprintPKcSt9__va_list
06d8 gDF .text 0058 Base_Z7myprintPKcPv
1. http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gnu-
assembler/symver.html
2. http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-
linker/version.html
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: the mangling of ‘va_list’ has changed in GCC 4.4
Hello, On ketvirtadienis 28 Sausis 2010 21:37:15 Riku Voipio wrote: > Brilliant! This shall be the plan then: > > 1) identify affected libraries (Jakubs list as base?) > 2) provide patches for the libraries and submit them to BTS > 3) give maintainers X days to MU the libraries, after that proceed to > NMU them > 4) binNMU any packages using the functions with va_list parameters > 5) release squeeze ;) > 6) tell maintainers they are free to drop the symbol alias 1. Step 4 is optional and can be skipped. 2. WRT step 6, I don't think it is correct. Maintainer may only drop the alias when changing the name of the affected library package (most likely due to soname change). This step is not related to squeeze release. -- Modestas Vainius signature.asc Description: This is a digitally signed message part.
