Richard Sandiford writes:
> Dave Martin writes:
>> Another way of doing a similar thing is to mark __mylib_constructor
>> as undefined in all the objects that make up the library.
>>
>> Unfortunately, there seems to be no obvious way of doing that: the
>> ass
Dave Martin writes:
> Another way of doing a similar thing is to mark __mylib_constructor
> as undefined in all the objects that make up the library.
>
> Unfortunately, there seems to be no obvious way of doing that: the
> assembler generates undefined symbol references automatically for
> unresol
Sorry, should have included this in my last reply.
Dave Martin writes:
>> Also, remember this whole discussion is just to print a message and exit
>> nicely
>> in the case of someone using a currently incredibly rare function on an old
>> kernel!
>
> I'd say we want to notify the operating envir
Dave Martin writes:
>> To be honest I don't see the point in the more general indirected
>> approach; if we
>> want to be more general then I think we should use IFUNC (it would be the 1st
>> use of it, which means we may have to fix some issues but hey that's what
>> we're
>> here for).
>
> Does
Dave Martin writes:
> IFUNC doesn't solve the problem because either it gets resolved
> lazily (violating the above principle (*)), or we have to force _all_
> symbols to resolve at startup, with may have a significant impact on
> startup time for large programs.
IFUNCs are never resolved lazily;
Dave Martin writes:
> On Wed, Apr 13, 2011 at 11:11 PM, Michael Hope
> wrote:
>> Hi there. The address space randomisation feature in 2.6.35 and above
>> kernels breaks GCC's precompiled headers support. GCC works by
>> compiling the header once, dumping the internal format out to disk,
>> and
Michael Hope writes:
> Richard, the implementation uses NEON intrinsics so it'd be
> interesting to see if your pack/unpack patches apply to it.
Thanks for the heads up. FWIW, though, I don't think my changes
help here, because there are no strided loads and stores involved.
Jan's version doesn'
I realise this reply is academic; I'm happy to accept the decision.
For the record though...
Michael Hope writes:
> On Thu, Mar 10, 2011 at 11:51 PM, Richard Sandiford
> wrote:
>> On 9 March 2011 20:56, Michael Hope wrote:
>>> We currently use a feature branch / me
On 9 March 2011 20:56, Michael Hope wrote:
> We currently use a feature branch / merge request / merge / test /
> push approach in gcc-linaro. This works fine for a reasonable cost
> but can mean that patches sit unreviewed and unmerged for up to a
> month. Ramana, Andrew, and I had a talk about
