This is the mail archive of the
mailing list for the GCC project.
Re: libgo patch committed: Implement reflect.MakeFunc for 386
- From: Ian Lance Taylor <iant at google dot com>
- To: Rainer Orth <ro at cebitec dot uni-bielefeld dot de>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, "gofrontend-dev at googlegroups dot com" <gofrontend-dev at googlegroups dot com>
- Date: Mon, 30 Sep 2013 08:44:36 -0700
- Subject: Re: libgo patch committed: Implement reflect.MakeFunc for 386
- Authentication-results: sourceware.org; auth=none
- References: <mcrvc1mx822 dot fsf at iant-glaptop dot roam dot corp dot google dot com> <ydd4n92bgq0 dot fsf at lokon dot CeBiTec dot Uni-Bielefeld dot DE> <CAKOQZ8wNtAS5MX6m=xif7cbdmV0uL5qMwBTm4-aNEbu-r-oacQ at mail dot gmail dot com> <yddzjqu9zd4 dot fsf at lokon dot CeBiTec dot Uni-Bielefeld dot DE>
On Mon, Sep 30, 2013 at 7:07 AM, Rainer Orth
> Ian Lance Taylor <email@example.com> writes:
>> On Mon, Sep 30, 2013 at 6:07 AM, Rainer Orth
>> <firstname.lastname@example.org> wrote:
>>> Ian Lance Taylor <email@example.com> writes:
>>>> Following up on my earlier patch, this patch implements the
>>>> reflect.MakeFunc function for 386.
>>>> Tom Tromey pointed out to me that the libffi closure support can
>>>> probably be used for this. I was not aware of that support. It
>>>> supports a lot more processors, and I should probably start using it.
>>>> The approach I am using does have a couple of advantages: it's more
>>>> efficient, and it doesn't require any type of writable executable
>>>> memory. I can get away with that because indirect calls in Go always
>>>> pass a closure value. So even when and if I do change to using libffi,
>>>> I might still keep this code for amd64 and 386.
>>> Unfortunately, this patch (and undoubtedly the corresponding amd64 one)
>>> break Solaris/x86 libgo bootstrap with native as:
>> Unfortunately I think I'll have to somehow disable this functionality
>> on systems with assemblers that do not understand the .cfi directives,
>> as otherwise calling panic in a function created with MakeFunc will
>> not work.
> Alternatively, one could hand-craft the .eh_frame section for such
> systems along the lines of libffi/src/x86/sysv.S: ugly, but doable.
Yeah. I'm not going to do that myself. But I would be happy to
approve a patch for that if somebody else wants to write it.