gmane.os.cygwin.devel

Re: 64bit: C++ templates

Kai Tietz — 2013-05-23T09:58:31

2013/5/23 Kai Tietz schrieb:

A link to that problem: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742

Kai

Re: 64bit: C++ templates

Corinna Vinschen — 2013-05-23T08:46:16

And what kind of action will trigger the SEGV?


Corinna

Re: 64bit: C++ templates

Kai Tietz — 2013-05-23T08:26:24

Hi Yaakov,

A bit off-topic, but there is a better solution for bug c++/56742.
See recent attachment to this PR on gcc's bz for the patch.  It
deprecates my patch to config/i386/i386.c about this subject.

Kai

Re: 64bit: C++ templates

Yaakov (Cygwin/X — 2013-05-22T19:34:09

No, I haven't had time to look into it.


e.g. running gtk-demo (from the gtk2.0-demo package).


Yaakov

Re: 64bit: C++ templates

Corinna Vinschen — 2013-05-22T08:10:13

Hi Yaakov,

On May 20 11:26, Corinna Vinschen wrote:

Any more info here?


Assuming the build worked, how can one reproduce this SEGV?


Thanks,
Corinna

Re: 64bit: C++ templates

Yaakov (Cygwin/X — 2013-05-21T23:45:45

GCC 4.8.1 is due out this week or next, so if it's already in the 
branch, I can try it then.


Yaakov

Re: 64bit: C++ templates

Corinna Vinschen — 2013-05-21T11:06:30

Never mind, I found the patch:

http://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_8-branch/gcc/cp/decl2.c?r1=197830&r2=199104&view=patch

Yaakov, any chance you can try that?


Thanks,
Corinna

Re: 64bit: C++ templates

Corinna Vinschen — 2013-05-21T10:13:01

Do you have a direct link to this issue?


Thanks,
Corinna

Re: 64bit: C++ templates

Kai Tietz — 2013-05-20T13:14:51

Beside the ongoing testings I do to solve this issue for binutils, it
might be of interest to see if change referenced at

c++/57317 might have impact on the template-issue here?

Cheers,
Kai

Re: 64bit: C++ templates

Corinna Vinschen — 2013-05-20T09:26:14

Hi Yaakov,

On May 20 01:59, Yaakov (Cygwin/X) wrote:

well, this is not exactly related to the medium/large code model
introduction but rather a feature of gcc 4.8.  The same problematic
symbols are generated in the small code model in 4.8, but not with gcc
4.7.2.


Dunno, but more info on that might help my collegues to fix the issue.


This is a weird one!  Maybe there's still some bug in the large model
code generation?!?  OTOH, if that's only related to this kind of symbol
it might be a related issue.  Can you check if setting
-fvisibility-inlines-hidden or -fno-visibility-inlines-hidden changes
the outcome?


Sure!


Thanks,
Corinna

Re: 64bit: C++ templates

Yaakov (Cygwin/X — 2013-05-20T06:59:39

Is that surprising, given that PE-COFF medium/large code models were 
only added to trunk (AFAIK) post-4.8?


This seems to fix harfbuzz wrt gtk2; gtk3 still isn't working, but I'm 
not sure it's related yet.


With this, the link succeeded but I got SEGVs in one of the same symbols 
that failed to link previously.


Please keep me posted.


Yaakov

Re: 64bit: C++ templates

Corinna Vinschen — 2013-05-16T08:25:34

Hi Yaakov,

On May 15 11:32, Kai Tietz wrote:

Yesterday it turned out that the visibility stuff is not the real
problem.  Mingw gcc 4.8 also produces the same set of symbols, but it
doesn't fail when linking.

Some more testing now showed clearly that this problem is related to the
high address used as base addresses in the Cygwin toolchain.  If you
build the harfbuzz DLL not with

  -Wl,--enable-auto-image-base

but instead with a fixed address in the lower 31 bit address area,
for instance

  -Wl,--image-base -Wl,0x7ff00000

the problem disappears and you can successfully build the DLL.
Alternatively, you can also workaround this issue by building harfbuzz
with the -mcmodel=large option, which doesn't suffer this problem due to
the way symbols are only indirectly addressed.

Right now it seems this is a bfd bug in the relocation code.  The code
tests these 32 bit pc-relative offsets by checking if the result still
fits into 31 bit, without taking the high image base into account.
Also, for some reason thi

Re: native symlink support should fallback to default format if target missing

James Gregurich — 2013-05-15T15:07:50


Sent from my iPad

On May 14, 2013, at 8:28 PM, Christopher Faylor  wrote:


I hope so. I'm awfully tired of repeating them.

Re: 64bit: C++ templates

Kai Tietz — 2013-05-15T10:41:43

Sorry, wrong patch.  Proper is:

Index: decl2.c
===================================================================
--- decl2.c     (Revision 198882)
+++ decl2.c     (Arbeitskopie)
< at >< at > -2309,6 +2309,9 < at >< at > static bool
 determine_hidden_inline (tree decl)
 {
   return (visibility_options.inlines_hidden
+#ifdef TARGET_PECOFF
+         && !TARGET_PECOFF
+#endif
          /* Don't do this for inline templates; specializations might not be
             inline, and we don't want them to inherit the hidden
             visibility.  We'll set it here for all inline instantiations.  */

Re: 64bit: C++ templates

Kai Tietz — 2013-05-15T09:32:36

Hi,

the issue is a more general on and related to harfbuzz' use of
-fvisibility-inlines-hidden for mingw-targets, but not for cygwin
targets.  Btw the issue should be latent present for 32-bit too.
Well, nevertheless my test have shown that this option indeed fixes
that described issue.

Question here is if we shouldn't make visibility for inlines always
hidden on pe-coff targets.  I will think about this a bit.  The
following patch would do that:

Regards,
Kai

Index: decl2.c
===================================================================
--- decl2.c     (Revision 198882)
+++ decl2.c     (Arbeitskopie)
< at >< at > -2308,7 +2308,11 < at >< at > determine_visibility_from_class (tree decl, tree c
 static bool
 determine_hidden_inline (tree decl)
 {
-  return (visibility_options.inlines_hidden
+  return ((visibility_options.inlines_hidden
+#ifdef TARGET_PECOFF
+          || TARGET_PECOFF
+#endif
+         )
          /* Don't do this for inline templates; specializations might not be
             inline, and we don't want th

Re: native symlink support should fallback to default format if target missing

Christopher Faylor — 2013-05-15T02:28:21

Repetition is unnecessary.  Your points are simple and don't bear repeating.

Re: native symlink support should fallback to default format if target missing

James Gregurich — 2013-05-14T21:11:14


I'll repeat for emphasis... You don't need to do that. Just set the default form symlink and reply on a post-processing tool to update the symlink once the conditions are met.

Re: native symlink support should fallback to default format if target missing

James Gregurich — 2013-05-14T21:04:38


Works for me.  The key is that the system must work as unix software expects in terms of the creation of symlinks. You don't want the filesystem in an invalid state that cannot be recovered from or is much harder to recover from. If you have that, you can post-process to update default format symlinks to native symlinks once the targets are known.

Re: native symlink support should fallback to default format if target missing

James Gregurich — 2013-05-14T21:04:22


You don't need to do that. Just leave it as a native default form symlink. One can use a command line tool to test the symlink and retry the creation of the native symlink at a later time. That works in practical use.

Re: native symlink support should fallback to default format if target missing

Christopher Faylor — 2013-05-14T16:42:09

I see 2. and 3. as basically the same thing.  By the logic advanced
here it seems like, for consistency, 2. should silently create a
cygwin symlink.  I don't think that's a good idea but I do think it
would at least be consistent.


Ugh.  Please no.  Silently modifying the filesystem is rather surprising
behavior.  It gives the user no control.

cgf

Re: native symlink support should fallback to default format if target missing

Corinna Vinschen — 2013-05-14T16:07:20

We're falling back to Cygwin symlinks here.  The check for the FS
capabilities is always done since, for instance, MVFS doesn't support
the SYSTEM bit so only .lnk files work as symlinks, and NFS supports
real symlinks so it gets real symlinks.


No, that won't happen.  When reading a symlink it will be used, not
overwritten with another one under some weird circumstances.
Consider:

  $ export CYGWIN=winsymlinks:native
  $ ln -s foo bar
  $ [... doing some other unrelated stuff, forgetting to unset CYGWIN...]
  $ find . -name baz

This will accidentally read all symlinks under CWD and convert them to
native symlinks.  Nope, not good.


Corinna