[Gcl-devel] Re: gcl on intel mac

[Camm Maguire]

Greetings!  Do you know why the following simple program does not call
the handler on macosx?

=============================================================================
f.c
=============================================================================
#include <sys/mman.h>
#include <stdio.h>
#include <signal.h>

void
h(int s,long c,void *scp,char *a) {

  printf("foo\n");

}

int
main(int argc,char * argv[]) {

  char b1[4096*2],*b=b1;
  struct sigaction siga;

  b=(char *)(((unsigned long)b+4095) & ~4095);
  siga.sa_handler=(void *)h;
  siga.sa_flags=SA_RESTART|SA_SIGINFO|SA_RESETHAND;
  sigemptyset(&siga.sa_mask);
  sigaction(SIGSEGV,&siga,0);
  mprotect(b,sizeof(b),PROT_READ);
  b[0]=1;
  return 0;
}
=============================================================================
Linux:
=============================================================================
./f
foo
Segmentation fault
=============================================================================
Mac:
=============================================================================
./f
Segmentation fault
=============================================================================

Take care,

Tim Daly <address@hidden> writes:

> ok. I've solved the copy problem.
> The build still fails.
> I left the console trace in /Users/camm/silver/console
>
>
> Camm Maguire wrote:
>> Greetings!
>>
>> Tim Daly <address@hidden> writes:
>>
>>   
>>> Hmmm. I did a clone of the same repo and it builds for me.
>>>
>>>     
>>
>> But never on the mac, right?  cp might have a slightly different
>> set of command line requirements.
>>
>> Take care,
>>
>>
>>   
>>> Camm Maguire wrote:
>>>     
>>>> Greetings!
>>>>
>>>> cp: /Users/camm/silver/mnt/linux/doc/spadhelp/ALGEBRA.help and 
>>>> /Users/camm/silver/mnt/linux/doc/spadhelp/Algebra.help are identical (not 
>>>> copied).
>>>> make[1]: *** [/Users/camm/silver/mnt/linux/doc/spadhelp/Algebra.help] 
>>>> Error 1
>>>> make: *** [all] Error 2
>>>>
>>>> Take care,
>>>>
>>>> Tim Daly <address@hidden> writes:
>>>>
>>>>         
>>>>> I put the latest copy in /Users/camm/silver
>>>>>
>>>>> cd /Users/camm/silver
>>>>> export AXIOM=`pwd`/mnt/(whatever you have been using)
>>>>> export PATH=$AXIOM/bin:$PATH
>>>>> make TESTSET=notests
>>>>>
>>>>> Camm Maguire wrote:
>>>>>             
>>>>>> OK.  In the meantime, as part of testing, is there anything simple I
>>>>>> can do to simply build the lisp part of axiom and skip the docs, sman,
>>>>>> ...?
>>>>>>
>>>>>> Take care,
>>>>>>
>>>>>> Tim Daly <address@hidden> writes:
>>>>>>
>>>>>>                   
>>>>>>> There is no reason to rush.
>>>>>>> There is not a lot of demand for Axiom on a Mac.
>>>>>>> I would just like to be sure that Axiom builds everywhere.
>>>>>>>
>>>>>>> Camm Maguire wrote:
>>>>>>>                         
>>>>>>>> cvs -z9 -q -d:pserver:address@hidden:/sources/gcl co -d \
>>>>>>>>   gcl-2.6.8pre -r Version_2_6_8pre gcl
>>>>>>>>
>>>>>>>> but...
>>>>>>>>
>>>>>>>> am chasing one small reloc bug on ppc mac, so a few minor tweaks could
>>>>>>>> still be forthcoming.
>>>>>>>>
>>>>>>>> Take care,
>>>>>>>>
>>>>>>>> Tim Daly <address@hidden> writes:
>>>>>>>>
>>>>>>>>                                 
>>>>>>>>> I normally tar-gzip a known-good snapshot of gcl that works
>>>>>>>>> everywhere and ship it with Axiom. Where will I find such a
>>>>>>>>> source directory to tar up?
>>>>>>>>>
>>>>>>>>> Camm Maguire wrote:
>>>>>>>>>                                         
>>>>>>>>>> Greetings!
>>>>>>>>>>
>>>>>>>>>> Tim Daly <address@hidden> writes:
>>>>>>>>>>
>>>>>>>>>>                                                   
>>>>>>>>>>> I don't understand the phrase "axiom needs some non-gcl fixes".
>>>>>>>>>>> Axiom only runs on gcl.
>>>>>>>>>>>
>>>>>>>>>>>                                                             
>>>>>>>>>> 18 making /Users/camm/axiom-20100501/obj/linux/lib/fnct-key.o from 
>>>>>>>>>> /Users/camm/axiom-20100501/int/lib/fnct-key.c
>>>>>>>>>> /Users/camm/axiom-20100501/int/lib/fnct-key.c: In function 
>>>>>>>>>> 'handle_function_key':
>>>>>>>>>> /Users/camm/axiom-20100501/int/lib/fnct-key.c:314: error: 'SIGCLD' 
>>>>>>>>>> undeclared (first use in this function)
>>>>>>>>>> /Users/camm/axiom-20100501/int/lib/fnct-key.c:314: error: (Each 
>>>>>>>>>> undeclared identifier is reported only once
>>>>>>>>>> /Users/camm/axiom-20100501/int/lib/fnct-key.c:314: error: for each 
>>>>>>>>>> function it appears in.)
>>>>>>>>>> make[3]: *** [/Users/camm/axiom-20100501/obj/linux/lib/fnct-key.o] 
>>>>>>>>>> Error 1
>>>>>>>>>>
>>>>>>>>>> Take care,
>>>>>>>>>>
>>>>>>>>>>                                                   
>>>>>>>>>>> Camm Maguire wrote:
>>>>>>>>>>>                                                             
>>>>>>>>>>>> Greetings!  OK, I think this port is basically done.  acl2 and 
>>>>>>>>>>>> maxima
>>>>>>>>>>>> check out, but axiom needs some non-gcl fixes it appears.  You 
>>>>>>>>>>>> might
>>>>>>>>>>>> want to check it out and let me know if you find any issues.  In my
>>>>>>>>>>>> home, gcl8 and gcl8a have traditional and ansi builds of the
>>>>>>>>>>>> Version_2_6_8pre branch.  The former is without C optimization for
>>>>>>>>>>>> testing purposes.  There is a difference between gcc-4.0 and 
>>>>>>>>>>>> gcc-4.2.
>>>>>>>>>>>> You can toggle via CC=gcc-4.2 ./configure && make when making gcl.
>>>>>>>>>>>>
>>>>>>>>>>>> Take care,
>>>>>>>>>>>>
>>>>>>>>>>>> Tim Daly <address@hidden> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>                                                                    
>>>>>>>>>>>>      
>>>>>>>>>>>>> I see the file /tmp/gazonk_9540_0.c, .data, and .lsp
>>>>>>>>>>>>> in /tmp but I do not see the .h file.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There is nothing in the system logs.
>>>>>>>>>>>>> There is plenty of disk space.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Camm Maguire wrote:
>>>>>>>>>>>>>                                                                   
>>>>>>>>>>>>>                   
>>>>>>>>>>>>>> Greetings!  When trying to build acl2, I reliably get
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Error: Cannot create the file /tmp/gazonk_9540_0.h.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> on your machine, but not Matt's ppc mac.  This can only happen 
>>>>>>>>>>>>>> if the
>>>>>>>>>>>>>> following returns NULL:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> FILE *
>>>>>>>>>>>>>> fopen_not_dir(char *filename,char * option) {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   struct stat ss;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   if (!stat(filename,&ss) && S_ISDIR(ss.st_mode))
>>>>>>>>>>>>>>     return NULL;
>>>>>>>>>>>>>>   else
>>>>>>>>>>>>>>     return fopen(filename,option);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The file does not exist, and I can create it from a shell.  This 
>>>>>>>>>>>>>> may
>>>>>>>>>>>>>> have to do with some system file descriptor limits, or somesuch.
>>>>>>>>>>>>>> Could you please check your logs and see if anything is revealed?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Take care, 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tim Daly <address@hidden> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                                                                  
>>>>>>>>>>>>>>                                  
>>>>>>>>>>>>>>> It should be back now. -- Tim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Camm Maguire wrote:
>>>>>>>>>>>>>>>                                                                 
>>>>>>>>>>>>>>>                                                 
>>>>>>>>>>>>>>>> Hi Tim!  I think axiom-developer.com is down.  Please let me 
>>>>>>>>>>>>>>>> know when
>>>>>>>>>>>>>>>> its convenient to reestablish.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Take care,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Tim Daly <address@hidden> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>                                                                
>>>>>>>>>>>>>>>>                                                                
>>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>>>> I second the motion. PPC macs are unsupported for Axiom.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Matt Kaufmann wrote:
>>>>>>>>>>>>>>>>>                                                               
>>>>>>>>>>>>>>>>>                                                               
>>>>>>>>>>>>>>>>>                     
>>>>>>>>>>>>>>>>>> Hi, Camm --
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm impressed by the complexity with which you have to deal! 
>>>>>>>>>>>>>>>>>>  But I
>>>>>>>>>>>>>>>>>> don't know this kind of technical stuff; I just operate as a 
>>>>>>>>>>>>>>>>>> dumb Lisp
>>>>>>>>>>>>>>>>>> user.  Regarding:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>                                                              
>>>>>>>>>>>>>>>>>>                                                              
>>>>>>>>>>>>>>>>>>                                         
>>>>>>>>>>>>>>>>>>>> Are the
>>>>>>>>>>>>>>>>>>>> ppc machines still to be supported?
>>>>>>>>>>>>>>>>>>>>                                                            
>>>>>>>>>>>>>>>>>>>>                                                            
>>>>>>>>>>>>>>>>>>>>                                                            
>>>>>>>>>>>>>>>>>>>>                      
>>>>>>>>>>>>>>>>>> Although I have a ppc Mac on my desktop, I have an Intel Mac 
>>>>>>>>>>>>>>>>>> laptop
>>>>>>>>>>>>>>>>>> that I use for actual work.  (The ppc Mac is basically a 
>>>>>>>>>>>>>>>>>> terminal.)
>>>>>>>>>>>>>>>>>> So if we generalize from me as a single data point, ppc isn't
>>>>>>>>>>>>>>>>>> important: I'd be very happy to have GCL running on my Intel 
>>>>>>>>>>>>>>>>>> Mac and
>>>>>>>>>>>>>>>>>> wouldn't really care much about it running on my ppc Mac.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks --
>>>>>>>>>>>>>>>>>> -- Matt
>>>>>>>>>>>>>>>>>>    From: Camm Maguire <address@hidden>
>>>>>>>>>>>>>>>>>>    Date: Tue, 29 Jun 2010 19:47:30 -0400
>>>>>>>>>>>>>>>>>>    X-SpamAssassin-Status: No, hits=-2.6 required=5.0
>>>>>>>>>>>>>>>>>>    X-UTCS-Spam-Status: No, hits=-242 required=165
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    Greetings!  Pleased to announce that I've got this 
>>>>>>>>>>>>>>>>>> working, though the
>>>>>>>>>>>>>>>>>>    final incarnation is still not clear in my mind.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    1) gcc-4.0, the standard on this box, passes all function 
>>>>>>>>>>>>>>>>>> calls
>>>>>>>>>>>>>>>>>>    through a jump table.  gcc-4.2 removes the section 
>>>>>>>>>>>>>>>>>> entirely and does
>>>>>>>>>>>>>>>>>>    calls directly.  This is of course one instruction 
>>>>>>>>>>>>>>>>>> faster.  The
>>>>>>>>>>>>>>>>>>    former, however, allows one not to relocate the .text 
>>>>>>>>>>>>>>>>>> section at all,
>>>>>>>>>>>>>>>>>>    as there are no external references.  (The other local 
>>>>>>>>>>>>>>>>>> section
>>>>>>>>>>>>>>>>>>    referenced is a "pointers" section, which gcc-4.2 also 
>>>>>>>>>>>>>>>>>> emits.  This
>>>>>>>>>>>>>>>>>>    definitely appears slower than say i386 Linux, as one has 
>>>>>>>>>>>>>>>>>> to do an
>>>>>>>>>>>>>>>>>>    extra copy and address indirection for each referenced 
>>>>>>>>>>>>>>>>>> variable. But
>>>>>>>>>>>>>>>>>>    there appears to be no choice here.)  
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    The reason why skipping the relocation might be important 
>>>>>>>>>>>>>>>>>> is because
>>>>>>>>>>>>>>>>>>    the bfd library does not do this correctly, and gcl will 
>>>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>>>>    override some of its functions.  Which means expanding, 
>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>    contracting, our local patch, and this begins to appear 
>>>>>>>>>>>>>>>>>> fragile.  So
>>>>>>>>>>>>>>>>>>    question one is whether gcc-4.2 needs supporting on the 
>>>>>>>>>>>>>>>>>> mac.  On a
>>>>>>>>>>>>>>>>>>    totally open source platform this question is ridiculous 
>>>>>>>>>>>>>>>>>> as one must
>>>>>>>>>>>>>>>>>>    keep abreast with the latest, but I've been told that 
>>>>>>>>>>>>>>>>>> Apple has
>>>>>>>>>>>>>>>>>>    decided not to make latest gcc available for licensing 
>>>>>>>>>>>>>>>>>> reasons (latest
>>>>>>>>>>>>>>>>>>    is 4.4, soon to be 4.5).  So what is the proper, 
>>>>>>>>>>>>>>>>>> hopefully stable
>>>>>>>>>>>>>>>>>>    target for this port?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    2) The relocation records for either compiler are 
>>>>>>>>>>>>>>>>>> experimentally
>>>>>>>>>>>>>>>>>>    observed to be either SECTDIFF_32, PAIR_32, DISP32, or 
>>>>>>>>>>>>>>>>>> 32.  I don't
>>>>>>>>>>>>>>>>>>    know if I can count on this, but this is all I can test.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    3) I've been told that mach-o has a 64bit format that 
>>>>>>>>>>>>>>>>>> differs in some
>>>>>>>>>>>>>>>>>>    respects.  Are these machines out there?  Are they 
>>>>>>>>>>>>>>>>>> different?  Are the
>>>>>>>>>>>>>>>>>>    ppc machines still to be supported?  The ppc code 
>>>>>>>>>>>>>>>>>> (existing courtesy
>>>>>>>>>>>>>>>>>>    of Aurelien) does work on Matt's machine with a few minor 
>>>>>>>>>>>>>>>>>> bit rot
>>>>>>>>>>>>>>>>>>    changes.  But it does require a separate relocation file 
>>>>>>>>>>>>>>>>>> against a
>>>>>>>>>>>>>>>>>>    much earlier version of the bfd library.  I have not 
>>>>>>>>>>>>>>>>>> merged this with
>>>>>>>>>>>>>>>>>>    the intel code under one lib yet.  
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    This brings up the general question of the gcl 2.6.8 
>>>>>>>>>>>>>>>>>> release.  I had
>>>>>>>>>>>>>>>>>>    wanted to fix the mac port before releasing this.  
>>>>>>>>>>>>>>>>>> Currently, all
>>>>>>>>>>>>>>>>>>    Debian platforms have the latest which build all apps
>>>>>>>>>>>>>>>>>>    (maxima,acl2,axiom,hol88) without error on all 13 Debian 
>>>>>>>>>>>>>>>>>> platforms.
>>>>>>>>>>>>>>>>>>    All synchronous app versions are currently in Debian 
>>>>>>>>>>>>>>>>>> testing for the
>>>>>>>>>>>>>>>>>>    next release.  Debian as you all know feeds Ubuntu.  I'm 
>>>>>>>>>>>>>>>>>> hesitant
>>>>>>>>>>>>>>>>>>    about upgrading the local bfd library in the 2.6.8 source 
>>>>>>>>>>>>>>>>>> tree to the
>>>>>>>>>>>>>>>>>>    latest upstream source at this point, but perhaps for no 
>>>>>>>>>>>>>>>>>> good reason.
>>>>>>>>>>>>>>>>>>    Debian uses the externally supplied latest bfd without 
>>>>>>>>>>>>>>>>>> issue where it
>>>>>>>>>>>>>>>>>>    uses bfd at all.  gclcvs uses the local tree for mips and 
>>>>>>>>>>>>>>>>>> alpha
>>>>>>>>>>>>>>>>>>    patches, but this is not in heavy use yet.  I think Tim 
>>>>>>>>>>>>>>>>>> might on
>>>>>>>>>>>>>>>>>>    occasion use the local bfd library in the gcl source, but 
>>>>>>>>>>>>>>>>>> I really
>>>>>>>>>>>>>>>>>>    don't know who else uses this.  In any case, this might 
>>>>>>>>>>>>>>>>>> argue either
>>>>>>>>>>>>>>>>>>    to backport the intel mac work to the earlier bfd lib we 
>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>    alongside Aurelien's stuff, or to write the reloc stuff 
>>>>>>>>>>>>>>>>>> without bfd
>>>>>>>>>>>>>>>>>>    for the intel mac.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    Along these lines, the local gmp sources in the gcl tree 
>>>>>>>>>>>>>>>>>> do not
>>>>>>>>>>>>>>>>>>    compile on the intel mac either.  I had to compile 
>>>>>>>>>>>>>>>>>> upstream latest
>>>>>>>>>>>>>>>>>>    externally, and patch that too (minor) to boot.  I've 
>>>>>>>>>>>>>>>>>> been told there
>>>>>>>>>>>>>>>>>>    is some mechanism for the user to just install gmp on the 
>>>>>>>>>>>>>>>>>> mac, but I
>>>>>>>>>>>>>>>>>>    don't know how hard this is, and whether therefore we 
>>>>>>>>>>>>>>>>>> need to provide
>>>>>>>>>>>>>>>>>>    the local convenience copy.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    4) There appears to be no explicit section flag (set by 
>>>>>>>>>>>>>>>>>> bfd at least)
>>>>>>>>>>>>>>>>>>    which indicates that all relocation records refer to 
>>>>>>>>>>>>>>>>>> locally appended
>>>>>>>>>>>>>>>>>>    "IMPORT" sections (jump_table, pointers).  So this is 
>>>>>>>>>>>>>>>>>> just an
>>>>>>>>>>>>>>>>>>    assumption at this point, but one that appears to be 
>>>>>>>>>>>>>>>>>> robust against a
>>>>>>>>>>>>>>>>>>    wide variety of code.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    5) It would appear that we can either a) try to integrate 
>>>>>>>>>>>>>>>>>> patches into
>>>>>>>>>>>>>>>>>>    bfd upstream, ... failed in the past, b) minimize a 
>>>>>>>>>>>>>>>>>> separately
>>>>>>>>>>>>>>>>>>    maintained patch preferably in one wrapper function to
>>>>>>>>>>>>>>>>>>    bfd_get_relocated_section_contents, or c) skip bfd and 
>>>>>>>>>>>>>>>>>> implement the
>>>>>>>>>>>>>>>>>>    relocation directly for the four relocation types 
>>>>>>>>>>>>>>>>>> mentioned above,
>>>>>>>>>>>>>>>>>>    and abort if others are found later.  This decision 
>>>>>>>>>>>>>>>>>> depends of course
>>>>>>>>>>>>>>>>>>    on the bugs, so here they are:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    a) No relocation records generated for jumptable and 
>>>>>>>>>>>>>>>>>> pointers
>>>>>>>>>>>>>>>>>>    sections, so bfd_get_relocated_section_contents returns 
>>>>>>>>>>>>>>>>>> garbage for
>>>>>>>>>>>>>>>>>>    these sections
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    b) bfd_mach_o_canonicalize_one_reloc miscalculates the 
>>>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>>>    symbol here:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>       unsigned int num = BFD_MACH_O_GET_R_SYMBOLNUM (symnum);
>>>>>>>>>>>>>>>>>>       res->addend = 0;
>>>>>>>>>>>>>>>>>>       res->address = addr;
>>>>>>>>>>>>>>>>>>       if (symnum & BFD_MACH_O_R_EXTERN)
>>>>>>>>>>>>>>>>>>         sym = syms + num;
>>>>>>>>>>>>>>>>>>       else
>>>>>>>>>>>>>>>>>>         {
>>>>>>>>>>>>>>>>>>           bfd_mach_o_section *sect;
>>>>>>>>>>>>>>>>>>           bfd_mach_o_section *ssp=NULL;
>>>>>>>>>>>>>>>>>>           int j;
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>           assert (num != 0);
>>>>>>>>>>>>>>>>>>           assert (num <= mdata->nsects);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>           /* sect=mdata->sections[num-1]; <-BUG */
>>>>>>>>>>>>>>>>>>           for (j=0;j<mdata->nsects;j++) /* Correct */
>>>>>>>>>>>>>>>>>>             if ((sect=mdata->sections[j]) && 
>>>>>>>>>>>>>>>>>> addr>=sect->addr && addr < sect->addr+sect->size)
>>>>>>>>>>>>>>>>>>               break;
>>>>>>>>>>>>>>>>>>           sym = sect->bfdsection->symbol_ptr_ptr;
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>           ...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    c) The relocation types SECTDIFF_32 and PAIR_32, via 
>>>>>>>>>>>>>>>>>> their howto
>>>>>>>>>>>>>>>>>>    definitions, erronously add in the output_section vma.  
>>>>>>>>>>>>>>>>>> Aurelien ran
>>>>>>>>>>>>>>>>>>    into the same I believe, leading to the solution of 
>>>>>>>>>>>>>>>>>> subtracting the
>>>>>>>>>>>>>>>>>>    vma from the relocation "addend" in a howto 'special 
>>>>>>>>>>>>>>>>>> function'.  The
>>>>>>>>>>>>>>>>>>    other platforms need this vma to be set as they use it 
>>>>>>>>>>>>>>>>>> correctly, so
>>>>>>>>>>>>>>>>>>    we would have to either conditionally not set it on this 
>>>>>>>>>>>>>>>>>> platform, or
>>>>>>>>>>>>>>>>>>    write a howto special function wrapper to set the addend, 
>>>>>>>>>>>>>>>>>> or directly
>>>>>>>>>>>>>>>>>>    patch bfd_mach_o_canonicalize_one_reloc, which needs 
>>>>>>>>>>>>>>>>>> doing anyway
>>>>>>>>>>>>>>>>>>    given the above.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    d) Likewise, the PAIR_32 addend is set to the address 
>>>>>>>>>>>>>>>>>> offset
>>>>>>>>>>>>>>>>>>    of the instruction, but this is already in place in the 
>>>>>>>>>>>>>>>>>> data, leading
>>>>>>>>>>>>>>>>>>    to it being added twice.  So similarly, the addend needs 
>>>>>>>>>>>>>>>>>> this quantity
>>>>>>>>>>>>>>>>>>    subtracted here.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    e) pc_relative relocs (DISP32) subtract the instruction 
>>>>>>>>>>>>>>>>>> address in
>>>>>>>>>>>>>>>>>>    bfd_get_relocated_section_contents, but the data is 
>>>>>>>>>>>>>>>>>> already relative
>>>>>>>>>>>>>>>>>>    so this is redundant.  The addend needs correcting as 
>>>>>>>>>>>>>>>>>> above in this
>>>>>>>>>>>>>>>>>>    case too. 
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    The current patch 1) provides two helper functions to set 
>>>>>>>>>>>>>>>>>> the pointer
>>>>>>>>>>>>>>>>>>    and jumptable sections 2) overrides 
>>>>>>>>>>>>>>>>>> bfd_mach_o_canonicalize_one_reloc
>>>>>>>>>>>>>>>>>>    with the one bug fix in b), and 3) wraps
>>>>>>>>>>>>>>>>>>    bfd_get_relocated_section_contents to skip .text, and 
>>>>>>>>>>>>>>>>>> call the
>>>>>>>>>>>>>>>>>>    functions in 1) when appropriate.  Supporting gcc-4.2 
>>>>>>>>>>>>>>>>>> will require
>>>>>>>>>>>>>>>>>>    relocating .text too, and patching 
>>>>>>>>>>>>>>>>>> bfd_mach_o_canonicalize_one_reloc
>>>>>>>>>>>>>>>>>>    with the changes for c, d, and e as well.  This is all 
>>>>>>>>>>>>>>>>>> doable, I'm
>>>>>>>>>>>>>>>>>>    mostly concerned with maintenance going forward.  Hence 
>>>>>>>>>>>>>>>>>> I'd love
>>>>>>>>>>>>>>>>>>    suggestions and feedback.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    Take care,
>>>>>>>>>>>>>>>>>>    -- 
>>>>>>>>>>>>>>>>>>    Camm Maguire                                          
>>>>>>>>>>>>>>>>>> address@hidden
>>>>>>>>>>>>>>>>>>    
>>>>>>>>>>>>>>>>>> ==========================================================================
>>>>>>>>>>>>>>>>>>    "The earth is but one country, and mankind its citizens." 
>>>>>>>>>>>>>>>>>>  --  Baha'u'llah
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>                                                              
>>>>>>>>>>>>>>>>>>                                                              
>>>>>>>>>>>>>>>>>>                                         
>>>>>>>>>>>>>>>>>                                                               
>>>>>>>>>>>>>>>>>                                                               
>>>>>>>>>>>>>>>>>                     
>>>>>>>>>>>>>>>>                                                                
>>>>>>>>>>>>>>>>                                                                
>>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>>                                                                 
>>>>>>>>>>>>>>>                                                 
>>>>>>>>>>>>>>                                                                  
>>>>>>>>>>>>>>                                  
>>>>>>>>>>>>>                                                                   
>>>>>>>>>>>>>                   
>>>>>>>>>>>>                                                                    
>>>>>>>>>>>>      
>>>>>>>>>>>                                                             
>>>>>>>>>>                                                   
>>>>>>>>>                                         
>>>>>>>>                                 
>>>>>>>                         
>>>>>>                   
>>>>>             
>>>>         
>>>
>>>
>>>     
>>
>>   
>
>
>
>

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