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 <d...@axiom-developer.org> 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 <d...@axiom-developer.org> 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 <d...@axiom-developer.org> 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 <d...@axiom-developer.org> 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:anonym...@cvs.sv.gnu.org:/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 <d...@axiom-developer.org> 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 <d...@axiom-developer.org> 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 <d...@axiom-developer.org> 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 <d...@axiom-developer.org> 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 <d...@axiom-developer.org> 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 <c...@maguirefamily.org>
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>> c...@maguirefamily.org
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ==========================================================================
>>>>>>>>>>>>>>>>>> "The earth is but one country, and mankind its citizens."
>>>>>>>>>>>>>>>>>> -- Baha'u'llah
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
--
Camm Maguire c...@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
_______________________________________________
Gcl-devel mailing list
Gcl-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gcl-devel
