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

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

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.

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

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:

/* 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

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

{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.