[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: SUBMISSION: New Library for kdesupport: indexlib
From:       Thiago Macieira <thiago () kde ! org>
Date:       2005-06-12 14:54:00
Message-ID: 200506121154.18233.thiago () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


Bernhard Rosenkraenzer wrote:
>On Sunday 12 June 2005 01:36, Thiago Macieira wrote:
>> But I diverge. The problem here is that g++ 3.4.x doesn't support
>> visibility and I'm still not sure about 4.0.x's reliability. Those g++
>> 3.4.x that have the visibility feature backported are broken.
>
>Broken in what way?
>We're using 3.4.x w/ visibility in Ark Linux, and we compiled most of
> KDE with -fvisibility=hidden, so far without problems...

I'm attaching the testcase. It was reduced from Qt4's qcoreapplication.cpp 
file. David Faure ran into this problem when QCoreApplication::self was 
not null, but calling QCoreApplication::instance() would return a null 
pointer.

Maksim and I worked on it for a few hours. The description I can come up 
with for the bug is:

This only happens when visibility is, by default, hidden 
(-fvisibility=hidden passed on the command-line). A static member 
variable in a class, declared visible, resets to hidden after being 
implemented, if there is a function using it before the implementation, 
and one after. (checkInstance is above, init is below in the testcase).

Since i386 ELF requires that non-PIC programs *copy* over the variable 
from the library into the final program, there are two copies of this 
variable. Under normal circumstances, only one of them will be seen. 
However, this bug is such that the QCoreApplication::init() function 
references the wrong of two variables.

Objdump reveals, for the first function:
  12:   8b 81 00 00 00 00       mov    0x0(%ecx),%eax
                        14: R_386_GOT32 QCoreApplication::self
  18:   83 38 00                cmpl   $0x0,(%eax)

While the second has:
  3a:   89 81 00 00 00 00       mov    %eax,0x0(%ecx)
                        3c: R_386_GOTOFF        QCoreApplication::self

Note the difference in relocation. The second relocation vanishes when 
linking the .o into .so.

Now you'll ask me: why didn't I report this? Because g++ 4.0.0 isn't 
affected, nor is the released g++ 3.4.3. It only happens on those 
versions that are patched by the distributor.
-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

2. Tó cennan his weorc gearu, ymbe se circolwyrde, wearð se cægbord and se 
leohtspeccabord, and þa mýs cómon lator. On þone dæg, he hine reste.

["something.ii" (text/x-c++src)]

class __attribute__((visibility("default"))) QCoreApplication 
{
    friend class QCoreApplicationPrivate;
public:
    static QCoreApplication *instance() { return self; }

private:
    void init();

    static QCoreApplication *self;
};

class __attribute__((visibility("default"))) QCoreApplicationPrivate 
{
public:
    static bool checkInstance(const char *method);
};

bool QCoreApplicationPrivate::checkInstance(const char *function)
{
    bool b = (QCoreApplication::self != 0);
    return b;
}

QCoreApplication *QCoreApplication::self = 0;

void QCoreApplication::init()
{
    QCoreApplication::self = this;
}
// Compile with:
// g++ -c -pipe -g -fvisibility=hidden -fvisibility-inlines-hidden -Wall -fPIC something.ii

[Attachment #6 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]