Re: rebaseall and cygstdc++-6.dll

2011-09-27 Thread Dave Korn
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

2011-09-26 Thread Marco Atzeri

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

2011-09-26 Thread Ryan Johnson

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

2011-09-25 Thread Dave Korn
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

2011-09-25 Thread Dave Korn
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

2011-09-25 Thread Chris Sutcliffe
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

2011-09-25 Thread Dave Korn
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

2011-09-25 Thread Yaakov (Cygwin/X)
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

2011-09-14 Thread Dave Korn
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

2011-09-13 Thread Yaakov (Cygwin/X)
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

2011-09-10 Thread Dave Korn
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



Re: rebaseall and cygstdc++-6.dll

2011-09-10 Thread Chris Sutcliffe

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

2011-09-10 Thread Dave Korn
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

2011-09-10 Thread Dave Korn
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



rebaseall and cygstdc++-6.dll

2011-09-09 Thread Chris Sutcliffe

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