gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Fwd: Patch for gcl-2.6.7 on MacOSX(10.4.2) to build maxima-5


From: 足立 聡
Subject: [Gcl-devel] Fwd: Patch for gcl-2.6.7 on MacOSX(10.4.2) to build maxima-5.9.[12] and so on.
Date: Fri, 4 Nov 2005 18:25:15 +0900


Dear Developers of GNU Common lisp,

About a week ago, I sent the following email to address@hidden
Recently, I noticed that only members of this mailing list are allowed
to post an email to the list. So, I registered myself in the mailing list
and now post my previous email again. Anyway, I am a user
of GCL and Maxima and look forward to reading emails from
address@hidden

                                                                Sincerely yours,
                                                                Satoshi Adachi

Begin forwarded message:

From: 足立 聡 <address@hidden>
Date: 2005年10月18日 16:25:45:JST
To: address@hidden
Cc: 足立 聡 <address@hidden>
Subject: Patch for gcl-2.6.7 on MacOSX(10.4.2) to build maxima-5.9. [12] and so on.


Dear Developers of GNU Common Lisp (GCL):

================================================================
         This reports a bug and its fix for gcl-2.6.7 to build
         maxima-5.9.[12] on MacOS X (10.4.2). The patch for gcl-2.6.7
         is placed at an almost end part of this email between two
         "===...===" lines. Other part in this email is written to
         transfer some information about the relocation in MacOS X
         to the maintainer of GCL, who may not be a user of MacOS X.
================================================================

I have been using GCL as the base languange on which Maxima is implemented.
My present personal environment for computation is MacOS X (10.4.2)
running on iBook (G4).

Recently, I used gcl-2.6.7 to build maxima-5.9.1 and found that
maxima-5.9.1 can not be complied as

---------------------------------------------------------------------- ---------
...
...
;      - Compiling source file
; "/Volumes/HFS+1/usr/local/src/GNU/maxima-5.9.1/src/ clmacs.lisp" Compiling /Volumes/HFS+1/usr/local/src/GNU/maxima-5.9.1/src/ clmacs.lisp.
End of Pass 1.

;; Note: Tail-recursive call of ALPHALESSP was replaced by iteration.
;; Note: Tail-recursive call of ALPHALESSP was replaced by iteration.
End of Pass 2.
OPTIMIZE levels: Safety=2, Space=2, Speed=3
Finished compiling binary-gcl/clmacs.o.

;      - Loading binary file "binary-gcl/clmacs.o"
Loading binary-gcl/clmacs.o
error: unknown relocation entry
Error in FUNCALL [or a callee]: Cannot get relocated section contents
---------------------------------------------------------------------- ---------

This problem is originated from the source file of GCL

        gcl-2.6.7/binutils/bfd/mach-o-reloc.c

at the line 1018. The source code around this line is the following:

---------------------------------------------------------------------- ---------
...
          switch (r_type)
            {
            case PPC_RELOC_HI16:
            case PPC_RELOC_HI16_SECTDIFF:
              value = ((instruction & 0xffff) << 16) | other_half;
              break;

            case PPC_RELOC_LO16:
            case PPC_RELOC_LO16_SECTDIFF:
              value = (other_half << 16) | (instruction & 0xffff);
              break;

            case PPC_RELOC_HA16:
            case PPC_RELOC_HA16_SECTDIFF:
              if (other_half & 0x8000) {
value = ((instruction & 0xffff) << 16) + (0xffff0000 | other_ha\
lf);
              } else {
                value = ((instruction & 0xffff) << 16) + other_half;
              }
              break;

            case PPC_RELOC_LO14:
            case PPC_RELOC_LO14_SECTDIFF:
              value = (other_half << 16) | (instruction & 0xfffc);
              break;

            case PPC_RELOC_BR24:
              value = instruction & 0x03fffffc;
              if (value & 0x02000000) value |= 0xfc000000;
              break;

            case PPC_RELOC_BR14:
              value = instruction & 0xfffc;
              if (value & 0x8000) value |= 0xffff0000;
              break;

            case PPC_RELOC_JBSR:
              value = other_half;
              break;

            default:
fprintf (stderr, "error: unknown relocation entry \n"); /* HERE */
              return false;
            }
        }
...
---------------------------------------------------------------------- ---------

I changed the above line marked by "/* HERE */" as

---------------------------------------------------------------------- --------- fprintf (stderr, "error: unknown relocation entry, r_type = 0x% x\n", r_type); ---------------------------------------------------------------------- ---------

in order to inspect what is the value of the varible "r_type" that caused
the error.

Then, I recomplied gcl-2.6.7 with this modification and tried to build
maxima-5.9.1 again. The error message became as follows:

---------------------------------------------------------------------- ---------
...
...
;      - Loading binary file "binary-gcl/kclmac.o"
Loading binary-gcl/kclmac.o
start address -T 0x157ec00 Finished loading binary-gcl/kclmac.o

;      - Compiling source file
; "/Volumes/HFS+1/usr/local/src/GNU/maxima-5.9.1/src/ clmacs.lisp" Compiling /Volumes/HFS+1/usr/local/src/GNU/maxima-5.9.1/src/ clmacs.lisp.
End of Pass 1.

;; Note: Tail-recursive call of ALPHALESSP was replaced by iteration.
;; Note: Tail-recursive call of ALPHALESSP was replaced by iteration.
End of Pass 2.
OPTIMIZE levels: Safety=2, Space=2, Speed=3
Finished compiling binary-gcl/clmacs.o.

;      - Loading binary file "binary-gcl/clmacs.o"
Loading binary-gcl/clmacs.o
error: unknown relocation entry, r_type = 0xf
---------------------------------------------------------------------- ---------

Namely, the variable "r_type" takes the value "0xf".

Next, I read the documentation about the general relocation mechanism
on MacOS X, which is bundled with MacOS X, and inspected the header files
under /usr/include/ that are related with relocation.

In the header file /usr/include/mach-o/ppc/reloc.h,
the enumeration type "reloc_type_ppc", which classifies the type of
each relocation on MacOS X, is defined as

---------------------------------------------------------------------- ---------
...
enum reloc_type_ppc
{
    PPC_RELOC_VANILLA,  /* generic relocation as discribed above */
    PPC_RELOC_PAIR,     /* the second relocation entry of a pair */
PPC_RELOC_BR14, /* 14 bit branch displacement (to a word address) */ PPC_RELOC_BR24, /* 24 bit branch displacement (to a word address) */
    PPC_RELOC_HI16,     /* a PAIR follows with the low half */
    PPC_RELOC_LO16,     /* a PAIR follows with the high half */
PPC_RELOC_HA16, /* Same as the RELOC_HI16 except the low 16 bits and the * high 16 bits are added together with the low 16 bits * sign extened first. This means if bit 15 of the low * 16 bits is set the high 16 bits stored in the
                         * instruction will be adjusted.
                         */
PPC_RELOC_LO14, /* Same as the LO16 except that the low 2 bits are not * stored in the instruction and are always zero. This * is used in double word load/store instructions.
                         */
PPC_RELOC_SECTDIFF, /* a PAIR follows with subtract symbol value */
    PPC_RELOC_PB_LA_PTR,/* prebound lazy pointer */
PPC_RELOC_HI16_SECTDIFF, /* section difference forms of above. a PAIR */ PPC_RELOC_LO16_SECTDIFF, /* follows these with subtract symbol value */
    PPC_RELOC_HA16_SECTDIFF,
    PPC_RELOC_JBSR,
    PPC_RELOC_LO14_SECTDIFF,
PPC_RELOC_LOCAL_SECTDIFF /* like PPC_RELOC_SECTDIFF, but the symbol
                                 referenced was local.  */
};
---------------------------------------------------------------------- ---------

The final item PPC_RELOC_LOCAL_SECTDIFF in the above list
for the enumeration type "reloc_type_ppc"
has the number 15 (0xf in hexadecimal), which is counted from 0 as usual.
I found that this relocation type PPC_RELOC_LOCAL_SECTDIFF
caused the reported error in gcl-2.6.7 to build maxima-5.9.1.

This item PPC_RELOC_LOCAL_SECTDIFF in the enumeration type "reloc_type_ppc"
seems to have been added quite recently by Apple.

I cannot find some written documentation for PPC_RELOC_LOCAL_SECTDIFF.
Accordingly, I inspected the source code of Darwin corresponding to
MacOS X (10.4.2), which is offered by Apple.

I had downloaded and expaned all the source files for Darwin.
In the directory under which all the source files for Darwin are stored,
I typed the following command:

find . -type f -exec grep -H -n PPC_RELOC_LOCAL_SECTDIFF '{}' .

This command told me that PPC_RELOC_LOCAL_SECTDIFF appears only
in the following source files:

        cctools-576.3/as/notes
        cctools-576.3/as/write_object.c
        cctools-576.3/include/mach-o/ppc/reloc.h
        cctools-576.3/include/notes
        cctools-576.3/ld/notes
        cctools-576.3/ld/ppc_reloc.c
        cctools-576.3/libstuff/notes
        cctools-576.3/libstuff/reloc.c
        cctools-576.3/otool/notes
        cctools-576.3/otool/ofile_print.c
        cctools-576.3/otool/ppc_disasm.c
        ld64-21/src/Readers/ObjectFileMachO.cpp
        ld64-21/src/Writers/ExecutableFileMachO.cpp

Among these files, I read cctools-576.3/ld/ppc_reloc.c in order to
known how the loader treats the relocation type PPC_RELOC_LOCAL_SECTDIFF.

It is found in the soruce file cctools-576.3/ld/ppc_reloc.c that
the relocation type PPC_RELOC_LOCAL_SECTDIFF is treated completely
in the same way as the other relocation type PPC_RELOC_SECTDIFF is treated
except for the treatment in one code fragment.

Except for the one code fragment, PPC_RELOC_LOCAL_SECTDIFF and
PPC_RELOC_SECTDIFF always appear in paralell in disjunctional conditions.
For example, their first appearance looks as

        ...
        else if(r_type == PPC_RELOC_SECTDIFF ||         /* HERE */
                r_type == PPC_RELOC_LOCAL_SECTDIFF ||   /* HERE */
                r_type == PPC_RELOC_HI16_SECTDIFF ||
                r_type == PPC_RELOC_LO16_SECTDIFF ||
                r_type == PPC_RELOC_LO14_SECTDIFF ||
                r_type == PPC_RELOC_HA16_SECTDIFF){
        ...

The only one code fragment in cctools-576.3/ld/ppc_reloc.c
in which PPC_RELOC_LOCAL_SECTDIFF is treated differently from
PPC_RELOC_SECTDIFF is the following:

        ...
        /*
         * Now build up the value of the relocated
         * expression one part at a time.  First set the
         * new value to the relocated r_value.
         */
        if(local_map->nfine_relocs != 0){
                /*
                 * Check to see if this reference is legal with
                 * respect to indirect sections.
                 */
                legal_reference(section_map, r_address,
local_map, r_value - local_map->s- >addr +
                                offset, i,
r_type != PPC_RELOC_LOCAL_SECTDIFF); /* HERE */
                value = fine_reloc_output_address(local_map,
                        r_value - local_map->s->addr,
                        local_map->output_section->s.addr);
        }
        else{
        ...

The function

        legal_reference(struct section_map *from_map,
                        unsigned long from_offset,
                        struct section_map *to_map,
                        unsigned long to_offset,
                        unsigned long from_reloc_index,
                        enum bool sectdiff_reloc)

that is called in the above code fragment in such a way that the last
argument "sectdiff_reloc" is set to "r_type != PPC_RELOC_LOCAL_SECTDIFF" is defined in another source file cctools-576.3/ld/ indirect_sections.c.

It is found by reading cctools-576.3/ld/indirect_sections.c that
the boolean flag "sectdiff_reloc" is used in the function legal_reference() only for turning on several extra conditional tests that are applied to
a given relocation entry. If the given relocation entry does not pass
one of these extra tests, an error message is printed and this is informed to
its caller by the returned value.
This means that if the given relocation entry is
a correct one, whether the boolean flag "sectdiff_reloc" is true or false does not affect the result that is returned by the function legal_reference().

This observation suggests that
the new relocation type PPC_RELOC_LOCAL_SECTDIFF can be treated
in our source code for any program completely in the same way as
PPC_RELOC_SECTDIFF is treated
under the assumption that only correct relocation entries appear
in our program.

This consideration allows me to rewrite the source file

        gcl-2.6.7/binutils/bfd/mach-o-reloc.c

as follows:

====================================================================== =========
--- mach-o-reloc.c.org  2004-03-12 17:16:03.000000000 +0900
+++ mach-o-reloc.c      2005-10-15 06:40:18.000000000 +0900
@@ -18,11 +18,14 @@
   PPC_RELOC_HA16_SECTDIFF            = 12, /* expects a pair */
   PPC_RELOC_JBSR                     = 13, /* expects a pair */
   PPC_RELOC_LO14_SECTDIFF            = 14, /* expects a pair */
+  PPC_RELOC_LOCAL_SECTDIFF           = 15, /* expects a pair */
   PPC_RELOC_NONE                     = 255
};
+#define PPC_RELOC_SENTINEL (PPC_RELOC_LOCAL_SECTDIFF+1)
+
/* Entries not suffixed by "PCREL" are expected to be absolute. Note, however, that the canonicalization routine does not require this. This means that adding a new pc-rel entry is as simple as adding the corresponding entries below, as
@@ -49,11 +52,14 @@
   BFD_MACH_O_PPC_RELOC_HI16_SECTDIFF   = 14,
   BFD_MACH_O_PPC_RELOC_LO16_SECTDIFF   = 15,
   BFD_MACH_O_PPC_RELOC_HA16_SECTDIFF   = 16,
-  BFD_MACH_O_PPC_RELOC_LO14_SECTDIFF   = 17,
-  BFD_MACH_O_PPC_RELOC_JBSR            = 18
+  BFD_MACH_O_PPC_RELOC_JBSR            = 17,
+  BFD_MACH_O_PPC_RELOC_LO14_SECTDIFF   = 18,
+  BFD_MACH_O_PPC_RELOC_LOCAL_SECTDIFF  = 19,
};
+#define BFD_MACH_O_PPC_RELOC_SENTINEL (BFD_MACH_O_PPC_RELOC_LOCAL_SECTDIFF+1)
+
#define BFD_MACH_O_R_ABS        0
#define BFD_MACH_O_R_SCATTERED  0x80000000
@@ -457,8 +463,28 @@
         false                                   /* pcrel_offset */
         ),
+  /* The jbsr instruction is assembled to the branch island. For
+ now, don't bother testing if the target can be reached directly. */
+
   /* 17 */
   HOWTO(
+        BFD_MACH_O_PPC_RELOC_JBSR,              /* type */
+        0,                                      /* right_shift */
+        2,                                      /* size */
+        26,                                     /* bitsize */
+        false,                                  /* pc_relative */
+        0,                                      /* bitpos */
+ complain_overflow_dont, /* complain_overflow */ + NULL, /* special_function */
+        "BFD_MACH_O_PPC_RELOC_JBSR",            /* name */
+        false,                                  /* partial_inplace */
+        0,                                      /* src_mask */
+        0,                                      /* dst_mask */
+        false                                   /* pcrel_offset */
+        ),
+
+  /* 18 */
+  HOWTO(
         BFD_MACH_O_PPC_RELOC_LO14_SECTDIFF,     /* type */
         0,                                      /* right_shift */
         2,                                      /* size */
@@ -474,25 +500,22 @@
         false                                   /* pcrel_offset */
         ),
-  /* The jbsr instruction is assembled to the branch island. For
- now, don't bother testing if the target can be reached directly. */
-
-  /* 18 */
+  /* 19 */
   HOWTO(
-        BFD_MACH_O_PPC_RELOC_JBSR,              /* type */
+        BFD_MACH_O_PPC_RELOC_LOCAL_SECTDIFF,    /* type */
         0,                                      /* right_shift */
         2,                                      /* size */
-        26,                                     /* bitsize */
+        32,                                     /* bitsize */
         false,                                  /* pc_relative */
         0,                                      /* bitpos */
complain_overflow_dont, /* complain_overflow */ - NULL, /* special_function */
-        "BFD_MACH_O_PPC_RELOC_JBSR",            /* name */
+ bfd_mach_o_sectdiff_reloc, /* special_function */
+        "BFD_MACH_O_PPC_RELOC_LOCAL_SECTDIFF",  /* name */
         false,                                  /* partial_inplace */
         0,                                      /* src_mask */
-        0,                                      /* dst_mask */
+        0xffffffff,                             /* dst_mask */
         false                                   /* pcrel_offset */
-        )
+        ),
};
@@ -513,6 +536,7 @@
   & reloc_howto_table [BFD_MACH_O_PPC_RELOC_HA16_SECTDIFF],
   & reloc_howto_table [BFD_MACH_O_PPC_RELOC_JBSR],
   & reloc_howto_table [BFD_MACH_O_PPC_RELOC_LO14_SECTDIFF],
+  & reloc_howto_table [BFD_MACH_O_PPC_RELOC_LOCAL_SECTDIFF],
   NULL,
   NULL,
@@ -528,7 +552,8 @@
   NULL,
   NULL,
   NULL,
-  NULL
+  NULL,
+  NULL,
};
@@ -601,7 +626,7 @@
      bfd *abfd ATTRIBUTE_UNUSED;
      bfd_reloc_code_real_type code;
{
-  if (code <= BFD_MACH_O_PPC_RELOC_JBSR) {
+  if (code < BFD_MACH_O_PPC_RELOC_SENTINEL) {
     return reloc_howto_table + code;
   } else {
     return NULL;
@@ -909,7 +934,8 @@
                r_type == PPC_RELOC_HI16_SECTDIFF ||
                r_type == PPC_RELOC_LO16_SECTDIFF ||
                r_type == PPC_RELOC_HA16_SECTDIFF ||
-               r_type == PPC_RELOC_LO14_SECTDIFF)
+               r_type == PPC_RELOC_LO14_SECTDIFF ||
+               r_type == PPC_RELOC_LOCAL_SECTDIFF)
         {
           struct scattered_relocation_info *srip = NULL;
           enum bfd_mach_o_rtype pair_r_type = PPC_RELOC_NONE;
@@ -948,7 +974,9 @@
       octets = relent->address * bfd_octets_per_byte (abfd);

- if (r_type == PPC_RELOC_VANILLA || r_type == PPC_RELOC_SECTDIFF)
+      if (r_type == PPC_RELOC_VANILLA ||
+          r_type == PPC_RELOC_SECTDIFF ||
+          r_type == PPC_RELOC_LOCAL_SECTDIFF)
         {
           switch (r_length)
             {
@@ -1015,7 +1043,7 @@
               break;

             default:
- fprintf (stderr, "error: unknown relocation entry\n"); + fprintf (stderr, "error: unknown relocation entry, r_type = 0x%x\n", r_type);
               return false;
             }
         }
@@ -1070,7 +1098,8 @@
           r_type == PPC_RELOC_HI16_SECTDIFF ||
           r_type == PPC_RELOC_LO16_SECTDIFF ||
           r_type == PPC_RELOC_HA16_SECTDIFF ||
-          r_type == PPC_RELOC_LO14_SECTDIFF)
+          r_type == PPC_RELOC_LO14_SECTDIFF ||
+          r_type == PPC_RELOC_LOCAL_SECTDIFF)
         {
           bfd_mach_o_sectdiff *sectdiff = (bfd_mach_o_sectdiff *)
             bfd_alloc (abfd, sizeof (bfd_mach_o_sectdiff));
@@ -1099,10 +1128,10 @@
       relent->howto = NULL;

- if ((r_type + (PPC_RELOC_LO14_SECTDIFF+1) * r_pcrel) < sizeof (to_howto)) + if ((r_type + PPC_RELOC_SENTINEL * r_pcrel) < sizeof (to_howto))
         {
           relent->howto =
- to_howto [r_type + (PPC_RELOC_LO14_SECTDIFF+1) * r_pcrel];
+            to_howto [r_type + PPC_RELOC_SENTINEL * r_pcrel];

           if (relent->howto ==
               & reloc_howto_table [BFD_MACH_O_PPC_RELOC_VANILLA_2])
====================================================================== =========

The GCL that is complied with this fix succeeds in building maxima-5.9.1.
Recently, Maxima was upgraded to maxima-5.9.2. I also confirmed that
the GCL with this fix succeeds in building maxima-5.9.2.

I have been using the maxima-5.9.2 that was build in this way
for about one week. I found no problem in the maxima that is related
with this fix for gcl-2.6.7.

I think that the maintainer of GCL may have already received
some bug report and its fix similar to this email, since I am sure
that there are a lot of users of GCL & Maxima on MacOS X.
In that case, this email may not bring any new information
to the maintainer of GCL. On the contrary, if the maintainer has not
yet received some email similar to this email, then please utilize
the information that this email contains to fix this bug in gcl-2.6.7
to build Maxima. If GCL cannot build Maxima on MacOSX, many people
in the world including me are very unhappy. So, please fix this problem
in any way.

Finally, sepeaking about the future development of
Binary File Dscriptor (BFD) library in the main branch,
someone needs to write a code for MacOS X to implement the extra tests
for the new relocation type PPC_RELOC_LOCAL_SECTDIFF
in order to keep the semantics of BFD including error checks
be compatible with the original semantics that is defined by Apple.

                                        Sincerely yours,

                                        Satoshi Adachi
                                        address@hidden

Department of Condensed Matter Physics
                                        Tokyo Insitute of Technology

                                        Tokyo, Megro Oookayama 2-12-1
                                        JAPAN

P.S Several years ago, I ported gcl-2.4.0 to MacOSX for my use.
However, I could not find enough time then to clean up the soruce code
to send a feedback. Now, my port became obsolate and I have no ncessecity
to clean up my code. I am very happy to use gcl-2.6.7 on MacOSX,
which was ported by someone.
In my port, I used dlopen() and related functions for dynamical loading
of object files and modified unexec() that is taken from GNU Emacs
to dump the memory image of GCL.
Just for historical interest, I put my dirty source code of
gcl-2.4.0 and gcl-2.5.3 for MacOSX in our anonymous ftp as

ftp://ftp.aa.ap.titech.ac.jp/pub/adachi/ dirty_source_code_of_GCL_for_MacOSX/
{gcl-2.4.0-MacOSX-dirty-socurce-code-by-S.Adachi.gnutar.gz,
gcl-2.5.3-MacOSX-dirty-source-code-by-S.Adachi.gnutar.gz}

I did not clean up anything. I am very sorry...
These tarfiles contain many LOG files and gabages.
These files are just for historical interest.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]