Weak symbols with GCC 3.4.4 - VxWorks

This is a discussion on Weak symbols with GCC 3.4.4 - VxWorks ; I'm a newbie with gcc.. Need some help.. I'm working with a module that worked perfectly fine with gcc 2.96.. This was Vxworks 5.5 for PowerPC.. Needed to switch to Vxworks 6.3.. with the new gcc version 3.4.4 (Wind River ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Weak symbols with GCC 3.4.4

  1. Weak symbols with GCC 3.4.4

    I'm a newbie with gcc.. Need some help..

    I'm working with a module that worked perfectly fine with gcc 2.96..
    This was Vxworks 5.5 for PowerPC..
    Needed to switch to Vxworks 6.3.. with the new gcc version 3.4.4 (Wind
    River vxworks-6.3) (built 20060510)

    Found this to be a bit stricter and was able to resolve most of the
    porting problems..
    But am finally stuck up with one last problem... There are a lot
    (5000+) weak symbols in the final binary.. At places, this was causing
    the module to call the wrong function of same name from a differnet
    sub-module and that resulted in a crash...

    I looked up at the various gcc options and fno-weak came to my
    rescue... ( Though gcc recommends against using this option) and I was
    able to resolve most of the errors..

    But for some of the last crashes that remain,I 'm stuck.. It's because
    using fno-weak for somefiless resulting in the following error::

    undefined reference to `typeinfo for XX`
    undefined reference to `vtable for YY'

    The num of such errors is 100+

    Before using fno-weak, these symbols 9vtable and typeinfo) were
    defined as weak objects ( " V " ). Using fno-weak caused these to be
    undefined

    In the original module (5.5), there were no weak symbols.. The ones
    which I needed to "strengthen" were localized symbols ( " t " ) The
    typeinfo and vtable stuff were altogather not there..

    Now I'm confused what to do next..
    Should I look at the original cause of the presence of so many weak
    symbols or should I better concentrate on the undefined symbols that
    I'mm getting now... Was using fno-weak the right option??

    Can anyone please provide some insight over this issue?? ANy help will
    be appreciated..

    Thanks in aticipation
    Shobhit


  2. Re: Weak symbols with GCC 3.4.4

    quizophobic@gmail.com writes:

    > But am finally stuck up with one last problem... There are a lot
    > (5000+) weak symbols in the final binary.. At places, this was causing
    > the module to call the wrong function of same name from a differnet
    > sub-module and that resulted in a crash...


    This implies a fatal flaw in the original code: if there are
    symbols that have the same linkage name (mangled name) but which
    correspond to different code (or data), then your program is
    ill-formed: it has multiple definitions of the same class (or inline
    function, or template) which are not identical.

    Your best bet is to fix the problem so this does not happen (by
    renaming clashing classes/templates to make sure they are unique).

    > I looked up at the various gcc options and fno-weak came to my
    > rescue...


    This may work in the short term, but if you are going to maintain
    that program, or port it to a new environment, the problem will
    bite you again (and again).

    > Before using fno-weak, these symbols 9vtable and typeinfo) were
    > defined as weak objects ( " V " ). Using fno-weak caused these to be
    > undefined
    >
    > In the original module (5.5), there were no weak symbols.. The ones
    > which I needed to "strengthen" were localized symbols ( " t " ) The
    > typeinfo and vtable stuff were altogather not there..


    If you want to replicate what gcc 2.96 [1] did, you can, but it's
    a lot of work (and you'll be better off just fixing the problem
    correctly): you can use 'objcopy --localize-symbols ...' to turn
    whatever symbols you want from "V" into "t".

    > Should I look at the original cause of the presence of so many weak
    > symbols or should I better concentrate on the undefined symbols that
    > I'mm getting now...


    You don't care how many weak symbols there are.

    You only care about weak symbols that correspond to non-identical
    code (or data), i.e. the ones that have "wrong function of the same
    name in different sub-module". A well-formed program isn't supposed
    to have any such symbols.

    Cheers,

    [1] See also: http://gcc.gnu.org/gcc-2.96.html
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

+ Reply to Thread