This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 64bit: C++ templates


Hi Yaakov,

On May 20 01:59, Yaakov (Cygwin/X) wrote:
> On 2013-05-16 03:25, Corinna Vinschen 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.
> 
> Is that surprising, given that PE-COFF medium/large code models were
> only added to trunk (AFAIK) post-4.8?

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.

> >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.
> 
> This seems to fix harfbuzz wrt gtk2; gtk3 still isn't working, but
> I'm not sure it's related yet.

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

> >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.
> 
> With this, the link succeeded but I got SEGVs in one of the same
> symbols that failed to link previously.

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?

> >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 this doesn't occur with all symbols, but only with
> >a very specific set of symbols (weak and a special kind of section
> >symbols).
> >
> >That's it for now.  We're still looking into providing a solution.
> 
> Please keep me posted.

Sure!


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]