On Feb 28, 2012, at 12:20 PM, Patrick Marlier wrote:
> Can I ask you to close this PR?
Done.
Jack,
Can I ask you to close this PR?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52042
Indeed, my bugzilla account is a simple one and I cannot to change the
bug status...
--
Patrick
On 02/07/2012 10:36 PM, Patrick Marlier wrote:
Hi,
The problem in this PR is that with PIE, getsectdata do
On Feb 15, 2012, at 11:18 AM, Patrick Marlier wrote:
> PS: this is my first commit so I hope I get it right. Otherwise do not
> hesitate to yell at me.
Thanks. I know of two people that will test and yell, if anything goes wrong.
I'll spin up a build...
Here the committed patch approved off-list by Mike Stump which fixed
PR/52042.
Tested on darwin10/11 with x86_64.
PS: this is my first commit so I hope I get it right. Otherwise do not
hesitate to yell at me.
Thanks.
--
Patrick.
2012-02-15 Iain Sandoe
Patrick Marlier
On Thu, Feb 09, 2012 at 08:54:14AM -0500, Patrick Marlier wrote:
> Hi Iain,
>
> On 02/09/2012 07:26 AM, Iain Sandoe wrote:
>> apologies for
>> (a) the extra loop - I missed a deprecation warning when I built your
>> last version ...
> Thanks! Actually, I saw the depreciation but I didn't found that
Hi Iain,
On 02/09/2012 07:26 AM, Iain Sandoe wrote:
apologies for
(a) the extra loop - I missed a deprecation warning when I built your
last version ...
Thanks! Actually, I saw the depreciation but I didn't found that dladdr.
(b) rolling two things into one mail ...
... (point 1 is related th
Hi Patrick,
apologies for
(a) the extra loop - I missed a deprecation warning when I built your
last version ...
(b) rolling two things into one mail ...
... (point 1 is related the pie issue, point 2 to linkage hassles).
On 9 Feb 2012, at 08:36, Iain Sandoe wrote:
I think refs (from libstd
Hi Patrick,
On 9 Feb 2012, at 05:10, Patrick Marlier wrote:
On 02/08/2012 12:12 AM, Jack Howarth wrote:
I believe the remaining libitm.c++/eh-1.C execution test failures
are due to
the weakref linker bug currently in Xcode 4.x (radr://10466868)
which I hae been
told will be fixed in the ne
On 02/08/2012 12:12 AM, Jack Howarth wrote:
I believe the remaining libitm.c++/eh-1.C execution test failures are due to
the weakref linker bug currently in Xcode 4.x (radr://10466868) which I hae been
told will be fixed in the next Xcode release after Xcode 4.3.
Jack
Humm... I
On 02/08/2012 04:14 PM, Mike Stump wrote:
On Feb 7, 2012, at 7: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.
If tests passed, ok for 4.7?
Ok. Thanks for all your hard work. If you w
On Feb 7, 2012, at 7: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.
> If tests passed, ok for 4.7?
Ok. Thanks for all your hard work. If you want to change it to include the
header an
Hi Patrick,
thanks for looking at this ..
On 8 Feb 2012, at 03:36, 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
On Tue, Feb 07, 2012 at 10:36:41PM -0500, Patrick Marlier wrote:
> Hi,
>
> 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 d
Hi,
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 s
14 matches
Mail list logo
