EmbDev.net

Forum: ARM programming with GCC/GNU tools Undefined symbols with assembler


Author: Nano2 Nano (nano2)
Posted on:

Rate this post
0 useful
not useful
Hi
I have he follow piece of assembler code powerpc.s running on powerpc6
redhat4.5
with GCC4.1.1

when i do a nm on the the object the symbol is undefined
Can you see whats wrong with the code i have below that the symbols
os_atomic_lock
os_atomic_unlock, etc are showing up as undefined ...


Please HELP .......
Thanks

nm powerpc.o |grep os_atomic_lock

0000000000000018 n os_atomic_lock
                 U os_atomic_lock
====
.set r0,0
.set SP,1
.set RTOC,2
.set r3,3
.set r4,4
.set r5,5
.set r6,6
.set r7,7
.set r8,8
.set r9,9

        .extern  os_atomic_add
        .extern  os_atomic_lock
        .extern  os_atomic_unlock
        .extern  os_atomic_set
        .extern  os_atomic_get
        .extern  os_atomic_init

        .file   "powerpc.s"
        .sect  H.10.NO_SYMBOL{PR} # I have no idea what this does

os_atomic_add:
        lwarx   r5, 0, r3
        add     r0, r4, r5
        stwcx.  r0, 0, r3
        bne-    os_atomic_add
        mr      r3, r0
        blr
os_atomic_lock:
        li      r0, 1
loop:
        # loop cheaply while not zero (this might speed things up)
        # lwz   r5, 0(r3)
        # cmpwi r5, 0
        # bne-  loop

        lwarx   r5, 0, r3
        cmpw    r0, r5
        beq-    loop
        stwcx.  r0, 0, r3
        bne-    loop
        isync
        blr
os_atomic_unlock:
        sync
os_atomic_init:
        li      r0, 0
        stw     r0, 0(r3)
        blr
os_atomic_set:
        #sync ?
        stw     r4, 0(r3)
        blr
os_atomic_get:
        #sync ?
        lwz     r3, 0(r3)
        blr

/usr/bin/as -mppc64 -a64 -as -o powerpc.o

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
Nano2 Nano wrote:
> Hi
> I have he follow piece of assembler code powerpc.s running on powerpc6
> redhat4.5
> with GCC4.1.1
I wonder then why you are asking this question on an ARM development
forum?

Nano2 Nano wrote:
>
> when i do a nm on the the object the symbol is undefined
> Can you see whats wrong with the code i have below that the symbols
> os_atomic_lock
> os_atomic_unlock, etc are showing up as undefined ...
I am not sure but some versions of GCC add a _ prefix to external
symbols, wheras teh assembler does not. So the high level language code
may be looking for _os_atomic_lock. To accommodate this possibility I
usually double define symbols thus:

.extern  os_atomic_lock
.extern  _os_atomic_lock

...

os_atomic_lock:
_os_atomic_lock:
        li      r0, 1

Take a look at the extern symbols in the code that references this to
see if it has silently prefixed the symbols. Also if you are using C++
you would have to specify that the symbol uses C linkage to avoid name
mangling.

If you still have problems you really should post teh build log. The
actual output from teh build will be far more useful that your
description.

Clifford

Author: Nano2 Nano (nano2)
Posted on:

Rate this post
0 useful
not useful
Clifford Slocombe wrote:
> Nano2 Nano wrote:
>> Hi
>> I have he follow piece of assembler code powerpc.s running on powerpc6
>> redhat4.5
>> with GCC4.1.1
> I wonder then why you are asking this question on an ARM development
> forum?
>
> Nano2 Nano wrote:
>>
>> when i do a nm on the the object the symbol is undefined
>> Can you see whats wrong with the code i have below that the symbols
>> os_atomic_lock
>> os_atomic_unlock, etc are showing up as undefined ...
> I am not sure but some versions of GCC add a _ prefix to external
> symbols, wheras teh assembler does not. So the high level language code
> may be looking for _os_atomic_lock. To accommodate this possibility I
> usually double define symbols thus:
>
> .extern  os_atomic_lock
> .extern  _os_atomic_lock
>
> ...

Clifford ,
I had the symbols defined as global like so

        .globl  .os_atomic_add
        .globl  .os_atomic_lock
        .globl  .os_atomic_unlock
        .globl  .os_atomic_set
        .globl  .os_atomic_get
        .globl  .os_atomic_init

.os_atomic_add:

But still got the undefined symbols so i declared them as extern  ....
The version of GCC is 4.1.1

Any ideas why this was so with defining them .globl ?

Thanks help much appreciated ..

> os_atomic_lock:
> _os_atomic_lock:
>         li      r0, 1
>
> Take a look at the extern symbols in the code that references this to
> see if it has silently prefixed the symbols. Also if you are using C++
> you would have to specify that the symbol uses C linkage to avoid name
> mangling.
>
> If you still have problems you really should post teh build log. The
> actual output from teh build will be far more useful that your
> description.
>
> Clifford

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
Its going to be far easier if you post the actual build log. All that
information is output to aid fault finding so you need to provide that
benefit to us too.

Author: Nano2 Nano (nano2)
Posted on:

Rate this post
0 useful
not useful
Nano2 Nano wrote:
> Clifford Slocombe wrote:
>> Nano2 Nano wrote:
>>> Hi
>>> I have he follow piece of assembler code powerpc.s running on powerpc6
>>> redhat4.5
>>> with GCC4.1.1
>> I wonder then why you are asking this question on an ARM development
>> forum?
>>
>> Nano2 Nano wrote:
>>>
>>> when i do a nm on the the object the symbol is undefined
>>> Can you see whats wrong with the code i have below that the symbols
>>> os_atomic_lock
>>> os_atomic_unlock, etc are showing up as undefined ...
>> I am not sure but some versions of GCC add a _ prefix to external
>> symbols, wheras teh assembler does not. So the high level language code
>> may be looking for _os_atomic_lock. To accommodate this possibility I
>> usually double define symbols thus:
>>
>> .extern  os_atomic_lock
>> .extern  _os_atomic_lock
>>
>> ...




> Clifford ,
> I had the symbols defined as global like so
>
>         .globl  .os_atomic_add
>         .globl  .os_atomic_lock
>         .globl  .os_atomic_unlock
>         .globl  .os_atomic_set
>         .globl  .os_atomic_get
>         .globl  .os_atomic_init
>
> .os_atomic_add:
>
> But still got the undefined symbols so i declared them as extern  ....
> The version of GCC is 4.1.1
>
> Any ideas why this was so with defining them .globl ?
>
> Thanks help much appreciated ..
>
>> os_atomic_lock:
>> _os_atomic_lock:
>>         li      r0, 1
>>
>> Take a look at the extern symbols in the code that references this to
>> see if it has silently prefixed the symbols. Also if you are using C++
>> you would have to specify that the symbol uses C linkage to avoid name
>> mangling.
>>
>> If you still have problems you really should post teh build log. The
>> actual output from teh build will be far more useful that your
>> description.
>>
>> Clifford

/home/t/cvs/4.3.7B1023/src/dsd/obj.ppc64/libdsd.so: undefined reference
to `os_atomic_get'


Clifford ,
This is what i have

g++  -L/home/t/cvs/F4.3.7B1023/src/lib/obj.ppc64 -L/usr/X11R6/lib64 -L
/home/t/cvs/F4.3.7B1023/src/lib/obj.ppc64 -L
/home/t/cvs/F4.3.7B1023/src/dsd/obj.ppc64 -L /usr/X11R6/lib64 -m64 -L
/usr/local64/lib -L /usr/local64/lib -L /usr/local64/lib -O -fPIC
-shared -o libon.so powerpc.o svr4.o subr.o cllist.o md5.o buffer.o
ftp.o network.o poller.o tp.o gettime.o base64.o oosubr.o rfile.o
qsort.o   -lnsl -ldl -lpthread -lCosNaming -lOB -lJTC


powerpc.o is the assembler code above and builds fine

when i do the nm on the new shared library
nm libon.so |grep os_atomic
0000000000000000 n _os_atomic_add
0000000000000000 n os_atomic_add
                 U os_atomic_add
0000000000000050 n _os_atomic_get
0000000000000050 n os_atomic_get
                 U os_atomic_get
000000000000003c n _os_atomic_init
000000000000003c n os_atomic_init
                 U os_atomic_init
0000000000000018 n _os_atomic_lock
0000000000000018 n os_atomic_lock
0000000000000048 n _os_atomic_set
0000000000000048 n os_atomic_set
                 U os_atomic_set
0000000000000038 n _os_atomic_unlock
0000000000000038 n os_atomic_unlock

I would expect the symbold to be declared different..

======================================================================== 
=================
So when I link the new shared library in with the following


c++  -L/home/t/cvs/F4.3.7B1023/src/lib/obj.ppc64 -L/usr/X11R6/lib64 -L
/home/t/cvs/F4.3.7B1023/src/lib/obj.ppc64 -L
/home/t/cvs/F4.3.7B1023/src/dsd/obj.ppc64 -L /usr/X11R6/lib64 -m64 -L
/usr/local64/lib -L /usr/local64/lib -L /usr/local64/lib -o enc enc.o
-ldsd -lnsl -ldl -lpthread -lCosNaming -lOB -lJTC -lon
/home/t/cvs/F4.3.7B1023/src/dsd/obj.ppc64/libdsd.so: undefined reference
to `os_atomic_lock'
/home/t/cvs/F4.3.7B1023/src/dsd/obj.ppc64/libdsd.so: undefined reference
to `os_atomic_add'
/home/t/cvs/FW_4.3.7B1023/src/dsd/obj.ppc64/libdsd.so: undefined
reference to `os_atomic_get'
/home/t/cvs/FW_4.3.7B1023/src/dsd/obj.ppc64/libdsd.so: undefined
reference to `os_atomic_init'
/home/t/cvs/FW_4.3.7B1023/src/dsd/obj.ppc64/libdsd.so: undefined
reference to `os_read_tick'
/home/t/cvs/FW_4.3.7B1023/src/dsd/obj.ppc64/libdsd.so: undefined
reference to `os_atomic_set'
/home/t/cvs/FW_4.3.7B1023/src/dsd/obj.ppc64/libdsd.so: undefined
reference to `os_atomic_unlock'
collect2: ld returned 1 exit status


Any ideas ....
Thanks

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
You don't have to re-quote the entire thread every time you know!

U means undefined, but you also have entries marked with 'n'. I am not
sure what 'n' means, it is not listed in the nm documentation. However
these 'n' symbols clearly are defined because they have addresses.
Moreover the addresses are at what  look like likely locations.

The log shows that you are using C++ compilation. Are you accessing
these symbols from C++ code? If so what do the declarations look like?
They need to have extern "C" linkage; for example:

extern "C" void os_atomic_add( void ) ;

or

extern "C"
{
  void os_atomic_add( void ) ;
  void os_atomic_lock( void ) ;
  ...
}

It seems to me that you are merely showing the result of your
investigation to some problem that you are not revealing. It would be
far more productive to explain what the problem is, since I suspect that
your investigation is going in the wrong direction and you are turning
up "red herrings". We need to know rather where you are coming from, not
where you have arrived at.

I see you are blissfully ignoring the fact that this is not a PowerPC
development forum!

Clifford

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.