This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: a question about gas
- From: Nick Clifton <nickc at redhat dot com>
- To: Lope De Vega <lope dot vega at yahoo dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Fri, 12 Oct 2007 17:06:35 +0100
- Subject: Re: a question about gas
- References: <925780.85206.qm@web45505.mail.sp1.yahoo.com>
Hi Lope,
I've uploaded a test case as you requested, there is
an acompayining README, and some other comments within
common.S
Phew - next time I will ask for a *simple* test case.
Anyway I fixed the problems with the test (it does not build on an x86_64 host
for example...) and I traced the source of the problem - you are expecting the
same assembler source code to be able to access a symbol's value regardless of
whether the code is compiled for a static library or a shared library. This is
not true. Shared libraries have a more complicated process for accessing a
variable's value because of the fact that the symbol's address is not known
until run time.
To see how it should be done, have a look at what the compiler does, eg:
% cat foo.c
extern int foo; int bar { return foo; }
% gcc -S foo.c -o foo.s.static
% gcc -S -fPIC foo.c -o foo.c.shared
% cat foo.s.static
[...]
bar:
pushl %ebp
movl %esp, %ebp
movl foo, %eax
[...]
% cat foo.s.shared
[...]
bar:
pushl %ebp
movl %esp, %ebp
call __i686.get_pc_thunk.cx
addl $_GLOBAL_OFFSET_TABLE_, %ecx
movl foo@GOT(%ecx), %eax
movl (%eax), %eax
[...]
So, this is not an assembler problem but rather a coding problem. Sorry.
Incidentally with regard to your comment in the common.S about structures, are
you aware of GAS's .struct pseudo-op ? You can achieve most of what you want
with this op, although the problem with accessing global values from shared
code will still exist.
Cheers
Nick