Re: [Axiom-developer] Re: [Gcl-devel] native relocation on Mac OS X

[Camm Maguire]

Greetings, and thanks as always for your helpful work with macosx.

Aurelien Chanudet <address@hidden> writes:

> As far as MacOS X is concerned, I feel the need to say that the PLT
> code is not compatible with the Mach-O object file format
> whatsoever. In short, Mach-O does not have any procedure linkage
> table, although it has a somewhat equivalent table which is called the
> indirect symbol table. Nor does MacOS X uses GNU ld. Instead, MacOS X
> uses its own linker which does not support the -Map switch.
> 

This I gathered.  The code checked in yesterday is nevertheless
intended to work as is in your situation, at least for the time being.
The reading and parsing of the plt table is optional, but desirable in
the long term as it facilitates future compiler optimizations.  The
only critical item is that the explicit table written into plt.h by
the makefile and used in plt.c compiles correctly as C code on your
machine, as I think it should.  Even this table is not required as
long as undefined symbol values remain in the executable, but its an
important safety to retain compatibility with future ld.


> In order to restore compatibility, I'd like to know if the PLT code
> can now be considered as a final and stable solution for Linux
> platforms. If this is so, I'll try to find as close a solution as
> possible involving the PLT counterpart for Mach-O. I'll also have to
> add a couple of Darwin specific gcc defined symbols to the table in
> o/plt.c. I'll also have to undo some work I did in order to affect a
> value to undefined symbols for Mach-O object files, given that we are
> now back to undefined symbols with null values.
> 

As for stability/finality of the existing plt code, I'd say its pretty
much done for 2.6.2, but I'd like to rethink in 2.7.z.  Reasons are
many, but among them are 1) the plt table is not written into the map
file on all Linux platforms, 2) the remaining linux platforms for
which native object relocation has not yet been enabled will also need
a .got table, which as far as I can tell is not output in human
readable form by any tool, 3) we need to think of a permanent way to
address the basic fundamental problem, which is that linking with ld
is considered an irreversible process in which information can be lost
-- we need all this information to relocate objects, and we are
basically relying on a fortuitous situation in that ld preserves
enough of it for us to get by for the time being.  I'd hate to have to
do it, but we might have to carry around or own ld.  I'd appreciate
your long term thoughts on this at some point.

Here's my suggestions for you for stable:

1) try the existing stable branch yet again, and see if it now
   compiles out of the box.  The only place I can think of it failing
   is in the _ name mangling/autodetection, but this should work.  If
   it does compile, you should be set to go for 2.6.2.  You should get
   an empty map file and si::*plt-table* alist.

2) don't change your bfd code to zero out the values of undefined
   symbols unless someone makes you do it!  These will be used when
   present, and if you can ensure their presence (as you arguably can
   as you are the author of the mach-o backend) then you don't need a
   full plt table in any case.

   The current code basically loops over the undefined symbols, calls
   my_plt to see if there is a match (in either the *plt-table*, which
   could be empty, or the explicit table compiled in via C).  If there
   is, the address returned is checked against the symbol value if its
   not zero to make sure everything is working right.  If the symbol
   value is zero, it is set to that returned by my_plt.  If after this
   step the symbol value is still zero, it is left undefined, which
   will result in an 'undefined symbol' error printout should any
   module being loaded try to refer to it.  There are no such in
   maxima,acl2,axiom at the present time, but should one ever arise,
   it can be added to the explicit table in plttest.c.

   So in sum I'd suggest not doing all the hard work you mentioned
   above for 2.6.2.  You have all the undefined symbol values, external
   and gcc-written, already, so all you need to do is get the same
   code-base everyone else uses to compile cleanly out of the box.  In
   2.7.x, we can think about robust long term solutions.  Even if ld
   dumps your undefined symbol values during the lifetime of 2.6.2,
   the explicit table will cover all the cases in external shared
   libs, and the gcc-written symbols (I think) cannot have their
   symbol values zeroed as they are static.

> I'd be most grateful if someone could point me to the piece of code
> which did change in the latest binutils. As far as I can tell, my
> Mach-O relocation code continues to work when linking against external
> symbols. See test code output below.
> 

This only changed in the elf32-i386 backend as a dynamic linker
optimization.  The diff was posted here:

http://mail.gnu.org/archive/html/gcl-devel/2004-02/msg00260.html

Take care,

> Aurelien
> 
> ----
> 
> $ cat testbfd.c
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <stdarg.h>
> 
> #include "bfd.h"
> #include "bfdlink.h"
> 
> #define MY_BFD_BOOLEAN bfd_boolean
> #define MY_BFD_FALSE FALSE
> #define MY_BFD_TRUE TRUE
> 
> void error (char *format, ...)
> {
>    va_list ap;
> 
>    va_start (ap, format);
>    vfprintf (stderr, format, ap);
>    fprintf (stderr, "\n");
>    fflush (stderr);
>    va_end (ap);
> 
>    exit (1);
> }
> 
> int main (int argc, char **argv)
> {
>      bfd *abfd;
>      char *filename;
>      asymbol **q;
>      long u, v;
> 
>      if (argc != 2)
>          error ("bad arg count");
> 
>      filename = argv[1];
> 
>      if ((abfd = bfd_openr (filename, 0)) == NULL)
>          error ("bfd_openr failed");
> 
>      if (!bfd_check_format (abfd, bfd_object))
>          error ("unrecognized format");
> 
>      if ((u = bfd_get_symtab_upper_bound (abfd)) < 0)
>          error ("cannot get symtab upper bound");
> 
>      if ((q = (asymbol **) alloca (u)) == NULL)
>          error ("cannot allocate wiggle room to store symtab");
> 
>      if ((v = bfd_canonicalize_symtab (abfd, q)) == NULL)
>          error ("cannot retrieve symbols");
> 
>      printf ("listing symbols:\n");
> 
>      for (u=0 ; u < v ; u++)
>      {
>          if (q[u]->name == NULL) {
>              printf ("warning: symbol without name\n");
>              continue;
>          }
> 
>          if (q[u]->section == NULL) {
>              printf ("warning: symbol %s has no section\n", q[u]->name);
>              continue;
>          }
> 
>          printf ("%10lx - %s%s\n", q[u]->value + q[u]->section->vma,
>              q[u]->name, bfd_is_und_section (q[u]->section) ? "
> (undefined)" : "");
>      }
> 
>      bfd_close (abfd);
> 
>      exit (0);
>      return 0;
> }
> 
> $ cat testfile.c
> 
> extern int boo ();
> 
> extern int moo ();
> 
> int bar () { return 0; }
> 
> int foo ()
> {
>      return bar () + boo () + moo ();
> }
> 
> $ uname -a ; ./testbfd testfile.o
> Darwin sabine.local 7.2.0 Darwin Kernel Version 7.2.0: Thu Dec 11
> 16:20:23 PST 2003; root:xnu/xnu-517.3.7.obj~1/RELEASE_PPC  Power
> Macintosh powerpc
> listing symbols:
>           0 - _bar
>          20 - _foo
>          90 - _boo (undefined)
>          70 - _moo (undefined)
>           0 - dyld_stub_binding_helper (undefined)
> 
> $ uname -a ; ./testbfd testfile.o
> Linux aljunied 2.4.18-newpmac #1 Thu Mar 14 22:44:49 EST 2002 ppc
> unknown
> listing symbols:
>           0 - testfile.c
>           0 -
>           0 -
>           0 -
>           0 - gcc2_compiled.
>           0 -
>           0 - bar
>          24 - foo
>           0 - boo (undefined)
>           0 - moo (undefined)
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah