Re: rebaseall and cygstdc++-6.dll
On 26/09/2011 04:15, Yaakov (Cygwin/X) wrote: > On Mon, 2011-09-26 at 02:15 +0100, Dave Korn wrote: >> The problem is in binutils, and the fact that it generates base relocs for >> entries from EH data that should be just ignored. >> >> http://sourceware.org/ml/binutils/2011-09/msg00174.html >> contains more detail, if you want to ask more let's do it on the binutils >> list. >> >> So to answer your question: the gcc language-specific runtime DLLs have to >> be built using the patched version of binutils, otherwise they break when >> they >> get rebased; that's why I'm rebuilding the gcc packages - having already >> locally rebuilt binutils. This will only be a big issue for anyone who wants >> to rebuild gcc from source themselves, the new packages I upload to the >> distro >> will still work for everyone regardless of what binutils they have installed >> and/or how or when or where they get rebased. > > Except that this issue doesn't affect only libstdc++, but any C++ > library which throws exceptions (as I have seen on my system). So we > really do need a patched binutils ASAP. True. And not just any library that throws exceptions, but any library that might be in the call stack at the time an exception is thrown and through which the libgcc eh code needs to unwind, so potentially even plain C libraries could be affected in the presence of mixed-language callbacks. That's a pretty rare combination fortunately, but most C++ libs that throw exceptions should be considered at risk. (I'm running the gcc testsuites against DLLs built with the new code, then I'm going to rebase them all and run the tests again, so it'll be a day or two before that's all done and I can check the fix in, but it'll be in time for the forthcoming 2.22 release). cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On 26/09/2011 2:28 AM, Marco Atzeri wrote: On 9/26/2011 5:15 AM, Yaakov (Cygwin/X) wrote: On Mon, 2011-09-26 at 02:15 +0100, Dave Korn wrote: The problem is in binutils, and the fact that it generates base relocs for entries from EH data that should be just ignored. http://sourceware.org/ml/binutils/2011-09/msg00174.html contains more detail, if you want to ask more let's do it on the binutils list. So to answer your question: the gcc language-specific runtime DLLs have to be built using the patched version of binutils, otherwise they break when they get rebased; that's why I'm rebuilding the gcc packages - having already locally rebuilt binutils. This will only be a big issue for anyone who wants to rebuild gcc from source themselves, the new packages I upload to the distro will still work for everyone regardless of what binutils they have installed and/or how or when or where they get rebased. Except that this issue doesn't affect only libstdc++, but any C++ library which throws exceptions (as I have seen on my system). So we really do need a patched binutils ASAP. There is an easy way to identify such libraries ? Just to know if I need to rebuild some of mines . If the problem affects any library which throws (as opposed to one which merely supports propagating/unwinding due to exceptions), then the presence of __cxa_throw in the output of nm would be a good indicator. If unwind handlers are also affected, then anything with a .eh_frame section is suspect (but that would be all C++ programs unless compiled in no-except mode). Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On 9/26/2011 5:15 AM, Yaakov (Cygwin/X) wrote: On Mon, 2011-09-26 at 02:15 +0100, Dave Korn wrote: The problem is in binutils, and the fact that it generates base relocs for entries from EH data that should be just ignored. http://sourceware.org/ml/binutils/2011-09/msg00174.html contains more detail, if you want to ask more let's do it on the binutils list. So to answer your question: the gcc language-specific runtime DLLs have to be built using the patched version of binutils, otherwise they break when they get rebased; that's why I'm rebuilding the gcc packages - having already locally rebuilt binutils. This will only be a big issue for anyone who wants to rebuild gcc from source themselves, the new packages I upload to the distro will still work for everyone regardless of what binutils they have installed and/or how or when or where they get rebased. Except that this issue doesn't affect only libstdc++, but any C++ library which throws exceptions (as I have seen on my system). So we really do need a patched binutils ASAP. There is an easy way to identify such libraries ? Just to know if I need to rebuild some of mines . Yaakov Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On Mon, 2011-09-26 at 02:15 +0100, Dave Korn wrote: > The problem is in binutils, and the fact that it generates base relocs for > entries from EH data that should be just ignored. > > http://sourceware.org/ml/binutils/2011-09/msg00174.html > contains more detail, if you want to ask more let's do it on the binutils > list. > > So to answer your question: the gcc language-specific runtime DLLs have to > be built using the patched version of binutils, otherwise they break when they > get rebased; that's why I'm rebuilding the gcc packages - having already > locally rebuilt binutils. This will only be a big issue for anyone who wants > to rebuild gcc from source themselves, the new packages I upload to the distro > will still work for everyone regardless of what binutils they have installed > and/or how or when or where they get rebased. Except that this issue doesn't affect only libstdc++, but any C++ library which throws exceptions (as I have seen on my system). So we really do need a patched binutils ASAP. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On 25/09/2011 21:31, Chris Sutcliffe wrote: > On 25 September 2011 02:07, Dave Korn wrote: >> I finally nailed this one down. Stray base relocs against references to >> symbols in discarded COMDAT sections remaining in the .eh_frame data cause >> the >> stack unwind lookup to get lost. Sourceware CVS is down right now but I'll >> be >> sending the attached to binutils when it's working again, and I've started >> building a 4.5.3-3 release. > > I'm confused, is the issue in binutils or gcc? If the issue is in > binutils, is rebuilding gcc going to help? Either way, glad you > nailed it! The problem is in binutils, and the fact that it generates base relocs for entries from EH data that should be just ignored. http://sourceware.org/ml/binutils/2011-09/msg00174.html contains more detail, if you want to ask more let's do it on the binutils list. So to answer your question: the gcc language-specific runtime DLLs have to be built using the patched version of binutils, otherwise they break when they get rebased; that's why I'm rebuilding the gcc packages - having already locally rebuilt binutils. This will only be a big issue for anyone who wants to rebuild gcc from source themselves, the new packages I upload to the distro will still work for everyone regardless of what binutils they have installed and/or how or when or where they get rebased. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On 25 September 2011 02:07, Dave Korn wrote: > I finally nailed this one down. Stray base relocs against references to > symbols in discarded COMDAT sections remaining in the .eh_frame data cause the > stack unwind lookup to get lost. Sourceware CVS is down right now but I'll be > sending the attached to binutils when it's working again, and I've started > building a 4.5.3-3 release. I'm confused, is the issue in binutils or gcc? If the issue is in binutils, is rebuilding gcc going to help? Either way, glad you nailed it! Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On 25/09/2011 07:07, Dave Korn wrote: > Sourceware CVS is down right now but I'll be > sending the attached to binutils when it's working again, Yeah, d'oh. Maybe I'll send the file with the actual patch in it, instead of the fresh diff I tried to generate when CVS wasn't working! Attached, JFTR. cheers, DaveK --- pe-dll.c.orig 2011-09-25 03:11:10.90625 +0100 +++ pe-dll.c 2011-09-25 03:11:10.78125 +0100 @@ -1398,6 +1398,16 @@ generate_reloc (bfd *abfd, struct bfd_li else if (!blhe || blhe->type != bfd_link_hash_defined) continue; } + /* Nor for Dwarf FDE references to discarded sections. */ + else if (bfd_is_abs_section (sym->section->output_section)) + { + /* These are the same section names that + _bfd_elf_default_action_discarded chooses to discard + relocs against. */ + if (!strcmp (s->name, ".eh_frame") + || !strcmp (s->name, ".gcc_except_table")) + continue; + } reloc_data[total_relocs].vma = sec_vma + relocs[i]->address; -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On 10/09/2011 02:57, Chris Sutcliffe wrote: > Hi All, > > Just a heads up around an issue I encountered with rtorrent after > executing rebaseall. I ran in to some forking issues so I executed > rebaseall after which rtorrent started to crash constantly during > various operations. Through trial and error I narrowed it down to > cygstdc++-6.dll being rebased. As a result I updated rebaseall to > exclude cygstdc++ (at line 110) by adding "-e '/cygstdc++-6.dll$/d'". > > I'm not sure what the issue is with rebasing cygstdc++-6.dll, but I > figured I should share my findings in case someone else runs in to a > similar issue. I finally nailed this one down. Stray base relocs against references to symbols in discarded COMDAT sections remaining in the .eh_frame data cause the stack unwind lookup to get lost. Sourceware CVS is down right now but I'll be sending the attached to binutils when it's working again, and I've started building a 4.5.3-3 release. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On 13/09/2011 22:20, Yaakov (Cygwin/X) wrote: > On Fri, 2011-09-09 at 21:57 -0400, Chris Sutcliffe wrote: >> Just a heads up around an issue I encountered with rtorrent after >> executing rebaseall. I ran in to some forking issues so I executed >> rebaseall after which rtorrent started to crash constantly during >> various operations. Through trial and error I narrowed it down to >> cygstdc++-6.dll being rebased. As a result I updated rebaseall to >> exclude cygstdc++ (at line 110) by adding "-e '/cygstdc++-6.dll$/d'". >> >> I'm not sure what the issue is with rebasing cygstdc++-6.dll, but I >> figured I should share my findings in case someone else runs in to a >> similar issue. > > http://cygwin.com/ml/cygwin-developers/2011-07/msg00058.html ?? It sounds like the same problem Corinna saw. It can't be the exact same bug as the one she linked to there, because that fix went into binutils ages ago, but it could conceivably be related. It turns out that it can also happen with DLLs that have been rebased down as well as up, after all. I suspect a typeinfo problem but am still investigating. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On Fri, 2011-09-09 at 21:57 -0400, Chris Sutcliffe wrote: > Just a heads up around an issue I encountered with rtorrent after > executing rebaseall. I ran in to some forking issues so I executed > rebaseall after which rtorrent started to crash constantly during > various operations. Through trial and error I narrowed it down to > cygstdc++-6.dll being rebased. As a result I updated rebaseall to > exclude cygstdc++ (at line 110) by adding "-e '/cygstdc++-6.dll$/d'". > > I'm not sure what the issue is with rebasing cygstdc++-6.dll, but I > figured I should share my findings in case someone else runs in to a > similar issue. http://cygwin.com/ml/cygwin-developers/2011-07/msg00058.html ?? Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On 11/09/2011 02:53, Dave Korn wrote: > Do you have a copy of the bad DLL that you could send me off-list? Oh, also any of the resulting rtorrent .stackdump files you might have lying around too. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On 11/09/2011 02:27, Chris Sutcliffe wrote: > On 10/09/2011 1:15 PM, Dave Korn wrote: >> On 10/09/2011 02:57, Chris Sutcliffe wrote: >>> I'm not sure what the issue is with rebasing cygstdc++-6.dll, but I >>> figured I should share my findings in case someone else runs in to a >>> similar issue. >> >> Is that the newest version that goes along with gcc-4.5.3-2? Off the top >> of my head I remember something like this happening before, but I thought >> we'd fixed it. I'll have to do some digging if it's still happening to >> the new one. > > Yes, that's with gcc-4.5.3-2. Tried building a C++ "hello world" and rebasing the cygstdc dll without any untoward side effects. It's also not the previous bug I was thinking of, that's definitely long gone. I'm building rtorrent now to see if that shows it up for me. Do you have a copy of the bad DLL that you could send me off-list? cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On 10/09/2011 1:15 PM, Dave Korn wrote: On 10/09/2011 02:57, Chris Sutcliffe wrote: I'm not sure what the issue is with rebasing cygstdc++-6.dll, but I figured I should share my findings in case someone else runs in to a similar issue. Is that the newest version that goes along with gcc-4.5.3-2? Off the top of my head I remember something like this happening before, but I thought we'd fixed it. I'll have to do some digging if it's still happening to the new one. Yes, that's with gcc-4.5.3-2. Cheers, Chris -- Chris Sutcliffe ir0nh...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On 10/09/2011 02:57, Chris Sutcliffe wrote: > Hi All, > > Just a heads up around an issue I encountered with rtorrent after > executing rebaseall. I ran in to some forking issues so I executed > rebaseall after which rtorrent started to crash constantly during > various operations. Through trial and error I narrowed it down to > cygstdc++-6.dll being rebased. As a result I updated rebaseall to > exclude cygstdc++ (at line 110) by adding "-e '/cygstdc++-6.dll$/d'". > > I'm not sure what the issue is with rebasing cygstdc++-6.dll, but I > figured I should share my findings in case someone else runs in to a > similar issue. Is that the newest version that goes along with gcc-4.5.3-2? Off the top of my head I remember something like this happening before, but I thought we'd fixed it. I'll have to do some digging if it's still happening to the new one. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
rebaseall and cygstdc++-6.dll
Hi All, Just a heads up around an issue I encountered with rtorrent after executing rebaseall. I ran in to some forking issues so I executed rebaseall after which rtorrent started to crash constantly during various operations. Through trial and error I narrowed it down to cygstdc++-6.dll being rebased. As a result I updated rebaseall to exclude cygstdc++ (at line 110) by adding "-e '/cygstdc++-6.dll$/d'". I'm not sure what the issue is with rebasing cygstdc++-6.dll, but I figured I should share my findings in case someone else runs in to a similar issue. Chris -- Chris Sutcliffe ir0nh...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple