Andi Kleen wrote:
It's certainly possible; of course it looses you any size savings. I
If it's all in one place and only on disk it doesn't really matter doesn't it?
It sure does for embedded applications. And, there backwards
compatibility is often less of an issue; you're not conc
Michael Meeks <[EMAIL PROTECTED]> writes:
> On Wed, 2008-04-02 at 07:56 -0700, Ian Lance Taylor wrote:
>> * Use GNU instead of SUSE, as this is for the GNU tools.
>
> Ah yes; you noticed the subliminal advertising ;-) If you're happy for
> me to trample on the GNU section namespace that's fi
> It's certainly possible; of course it looses you any size savings. I
If it's all in one place and only on disk it doesn't really matter doesn't it?
Even if loaded into memory as long as it is read in one block without
much seeking it shouldn't be that bad.
Backwards compatibility is alwa
Hi Ian / Andi,
On Wed, 2008-04-02 at 07:56 -0700, Ian Lance Taylor wrote:
> * Use GNU instead of SUSE, as this is for the GNU tools.
Ah yes; you noticed the subliminal advertising ;-) If you're happy for
me to trample on the GNU section namespace that's fine, but I hesitate
to tread there
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> * It seems that this is not backward compatible--an executable built
> in this way will not work if the dynamic linker does not know about
> it. The section should have the SHF_OS_NONCONFORMING bit set.
I wonder if it could be made backwards com
Michael Meeks <[EMAIL PROTECTED]> writes:
> Since almost all function relocations of this type are inside vtables,
> I implemented a new way of relocating vtables. This is a new
> '.suse.vtrelocs' section.
It's an interesting idea. Some comments:
* Use GNU instead of SUSE, as this is for
Hi guys,
I spent a little time recently researching ways to reduce the number of
unique named relocations that must be processed at dlopen time for large
C++ libraries[1]. Apologies for spamming all 3 lists like this, but it
touches all 3 projects.
Since almost all function reloca
