This is the mail archive of the
mailing list for the GCC project.
Re: [trans-mem,darwin] PR/52042 find tm_clone_table with PIE
- From: Patrick Marlier <patrick dot marlier at gmail dot com>
- To: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Cc: Mike Stump <mrs at gcc dot gnu dot org>, Jack Howarth <howarth at bromo dot med dot uc dot edu>, Iain Sandoe <developer at sandoe-acoustics dot co dot uk>
- Date: Tue, 28 Feb 2012 15:20:46 -0500
- Subject: Re: [trans-mem,darwin] PR/52042 find tm_clone_table with PIE
- References: <4F31EDC9.firstname.lastname@example.org>
Can I ask you to close this PR?
Indeed, my bugzilla account is a simple one and I cannot to change the
On 02/07/2012 10:36 PM, Patrick Marlier wrote:
The problem in this PR is that with PIE, getsectdata does not return the
position of tm_clone_table after the relocation.
While _dyld_get_image_vmaddr_slide(0) is enough for PIE, this is not
enough for dylib.
I did not find an easy API function to get position of the
tm_clone_table for a shared library (dylib). So the only way I found is
to get the mach_header address of the current dylib (via
_dyld_get_image_header_containing_address), iterate over loaded binaries
to find the current shared library and use _dyld_get_image_vmaddr_slide
to find the position.
Any other proposal (my knowledge of darwin is really limited)?
Can someone do a bootstrap and test libitm on darwin (I have a limited
access to a darwin machine, at least libitm tests pass)? Thanks!
If tests passed, ok for 4.7?
* config/darwin-crt-tm.c: Changes for PIE and shared library.