This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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: a question about gas


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


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