On Feb 6, 2013, at 7:44 AM, Jack Howarth wrote:
>Don't you need assembler support for the constructor init priorities to be
> called in the correct order when they reside in static or shared libraries?
No. It can be done without assembler support.
On Feb 6, 2013, at 6:23 AM, Alexander Potapenko wrote:
> I can't see how full init_priority support can work without proper aid
> from ld and/or the dynamic linker.
I can, but, I don't see that that matters much. It is a mere matter of
software. Rough sketch, define an encoding of the priority
On Wed, Feb 6, 2013 at 7:44 AM, Jack Howarth wrote:
> On Wed, Feb 06, 2013 at 07:36:06AM -0800, Ian Lance Taylor wrote:
>> On Wed, Feb 6, 2013 at 7:14 AM, Alexander Potapenko
>> wrote:
>> >
>> > I understand and fully support your desire for intra-module ctor/dtor
>> > priority.
>> > My comment
On Wed, Feb 06, 2013 at 07:36:06AM -0800, Ian Lance Taylor wrote:
> On Wed, Feb 6, 2013 at 7:14 AM, Alexander Potapenko wrote:
> >
> > I understand and fully support your desire for intra-module ctor/dtor
> > priority.
> > My comment was meant to reply to Mike (sorry for top-posting it,
> > again
On Wed, Feb 6, 2013 at 7:14 AM, Alexander Potapenko wrote:
>
> I understand and fully support your desire for intra-module ctor/dtor
> priority.
> My comment was meant to reply to Mike (sorry for top-posting it,
> again), who, as far as I understood him, wanted to see full
> init_priority support
On Wed, Feb 06, 2013 at 07:14:07PM +0400, Alexander Potapenko wrote:
> > Alexander,
> >I never claimed full init priority support however FSF gcc on darwin
> > currently
> > has no init priority support at all. Since Mike wanted to sort the
> > destructors as
> > well as the constructors and
> Alexander,
>I never claimed full init priority support however FSF gcc on darwin
> currently
> has no init priority support at all. Since Mike wanted to sort the
> destructors as
> well as the constructors and this achieves usable intra-module init priority
> support
> for FSF gcc darwin,
On Wed, Feb 06, 2013 at 06:23:50PM +0400, Alexander Potapenko wrote:
> I can't see how full init_priority support can work without proper aid
> from ld and/or the dynamic linker. According to the Apple people,
> those don't treat the cross-module priorities properly, so there's
> little that can be
I can't see how full init_priority support can work without proper aid
from ld and/or the dynamic linker. According to the Apple people,
those don't treat the cross-module priorities properly, so there's
little that can be done on the compiler side.
On Mon, Feb 4, 2013 at 11:39 PM, Mike Stump wro
On Mon, Feb 04, 2013 at 04:58:02PM -0500, Jack Howarth wrote:
> --- gcc/config/darwin.c (revision 195735)
> +++ gcc/config/darwin.c (working copy)
> @@ -89,7 +89,14 @@ typedef struct GTY(()) ctor_record {
>int position; /* original position */
> } ctor_record;
>
> +t
On Mon, Feb 04, 2013 at 03:24:41PM -0500, Jack Howarth wrote:
> --- /dev/null 2013-02-02 10:53:51.0 -0500
> +++ gcc/testsuite/g++.dg/asan/pr55617.C 2013-02-02 10:22:17.0
> -0500
> @@ -0,0 +1,8 @@
> +// { dg-do run { target { i?86-*-darwin* x86_64-*-darwin* } } }
There is not
Mike,
Attached is the requested qsort on destructors as well. After gcc branches
for 4.8, I would imagine the first baby step towards full constructor/destructor
priority support would be to remove...
/* The Apple assembler and linker do not support constructor priorities. */
#undef SUPPORTS_I
On Feb 4, 2013, at 12:24 PM, Jack Howarth wrote:
> Complete patch with testcase attached.
Thanks.
Committed revision 195737.
On Mon, Feb 04, 2013 at 12:12:36PM -0800, Mike Stump wrote:
> On Feb 4, 2013, at 11:23 AM, Mike Stump wrote:
> > On Feb 4, 2013, at 9:22 AM, Jack Howarth wrote:
> >> Currently darwin is unable to utilize libasan with constructors due to
> >> the lack of
> >> constructor priority support on that
On Feb 4, 2013, at 11:23 AM, Mike Stump wrote:
> On Feb 4, 2013, at 9:22 AM, Jack Howarth wrote:
>> Currently darwin is unable to utilize libasan with constructors due to the
>> lack of
>> constructor priority support on that target.
>
>> Okay for gcc trunk?
>
> Since asan doesn't need cross
On Feb 4, 2013, at 1:38 AM, Jakub Jelinek wrote:
> On Mon, Feb 04, 2013 at 10:22:48AM +0100, Richard Biener wrote:
>>> Okay for gcc trunk?
>>
>> But that does not work across translation units, no? ISTR collect2 has
>> support
>> to handle constructor priorities all by itself (at link time,
>>
On Feb 4, 2013, at 11:23 AM, Mike Stump wrote:
> On Feb 4, 2013, at 9:22 AM, Jack Howarth wrote:
>> Currently darwin is unable to utilize libasan with constructors due to the
>> lack of
>> constructor priority support on that target.
>
>> Okay for gcc trunk?
>
> Since asan doesn't need cross
On Feb 4, 2013, at 9:22 AM, Jack Howarth wrote:
> Currently darwin is unable to utilize libasan with constructors due to the
> lack of
> constructor priority support on that target.
> Okay for gcc trunk?
Since asan doesn't need cross translation unit priorities, the patch is
sufficient to fi
On Feb 4, 2013, at 6:22 AM, Jack Howarth wrote:
> I switched to the simple insertion of the asan priorities for two reasons...
>
> 1) Mike seemed unconvinced that the single qsort with the proposed
> sort_ctor_records
> of…
> would really be stable in absence of a second call to qsort.
This
Currently darwin is unable to utilize libasan with constructors due to the
lack of
constructor priority support on that target. The asan_finish_file routine
inserts an
essential __asan_init into the array of constructors (via the __mod_init_func
section).
However the insertion occurs at the e
On Mon, Feb 04, 2013 at 03:44:04PM +0100, Jakub Jelinek wrote:
> On Mon, Feb 04, 2013 at 09:22:27AM -0500, Jack Howarth wrote:
> >I switched to the simple insertion of the asan priorities for two
> > reasons...
> >
> > 1) Mike seemed unconvinced that the single qsort with the proposed
> > so
On Mon, Feb 04, 2013 at 09:22:27AM -0500, Jack Howarth wrote:
>I switched to the simple insertion of the asan priorities for two
> reasons...
>
> 1) Mike seemed unconvinced that the single qsort with the proposed
> sort_ctor_records
> of...
>
> +static int
> +sort_ctor_records (const void *
On Mon, Feb 04, 2013 at 09:22:27AM -0500, Jack Howarth wrote:
> On Mon, Feb 04, 2013 at 10:38:29AM +0100, Jakub Jelinek wrote:
> > On Mon, Feb 04, 2013 at 10:22:48AM +0100, Richard Biener wrote:
> > > > Okay for gcc trunk?
> > >
> > > But that does not work across translation units, no? ISTR coll
On Mon, Feb 04, 2013 at 10:38:29AM +0100, Jakub Jelinek wrote:
> On Mon, Feb 04, 2013 at 10:22:48AM +0100, Richard Biener wrote:
> > > Okay for gcc trunk?
> >
> > But that does not work across translation units, no? ISTR collect2 has
> > support
> > to handle constructor priorities all by itself
On Mon, Feb 4, 2013 at 10:55 AM, Alexander Potapenko wrote:
> On Mon, Feb 4, 2013 at 1:38 PM, Jakub Jelinek wrote:
>> On Mon, Feb 04, 2013 at 10:22:48AM +0100, Richard Biener wrote:
>>> > Okay for gcc trunk?
>>>
>>> But that does not work across translation units, no? ISTR collect2 has
>>> supp
On Mon, Feb 4, 2013 at 1:38 PM, Jakub Jelinek wrote:
> On Mon, Feb 04, 2013 at 10:22:48AM +0100, Richard Biener wrote:
>> > Okay for gcc trunk?
>>
>> But that does not work across translation units, no? ISTR collect2 has
>> support
>> to handle constructor priorities all by itself (at link time,
On Mon, Feb 04, 2013 at 10:22:48AM +0100, Richard Biener wrote:
> > Okay for gcc trunk?
>
> But that does not work across translation units, no? ISTR collect2 has
> support
> to handle constructor priorities all by itself (at link time,
> considering all inputs).
I wonder why the patch turned f
> But that does not work across translation units, no? ISTR collect2 has
> support
> to handle constructor priorities all by itself (at link time,
> considering all inputs).
> I wonder why darwin cannot use that mechanism to support init priorities?
>
> Richard.
(resending, sorry for top-posting
Constructor priorities on Darwin aren't supposed to work across
translation units, see http://llvm.org/bugs/show_bug.cgi?id=12556:
"""
I was told (by Apple folks) that darwin does not support cross-unit constructor
priorities, sorry. This is true for both gcc and llvm-gcc / clang. Within unit
prio
On Sun, Feb 3, 2013 at 5:57 AM, Jack Howarth wrote:
>Currently darwin is unable to utilize libasan with constructors due to the
> lack of
> constructor priority support on that target. The asan_finish_file routine
> inserts an
> essential __asan_init into the array of constructors (via the _
Currently darwin is unable to utilize libasan with constructors due to the
lack of
constructor priority support on that target. The asan_finish_file routine
inserts an
essential __asan_init into the array of constructors (via the __mod_init_func
section).
However the insertion occurs at the e
31 matches
Mail list logo
