FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 07-15-2010, 05:43 PM
Aurelien Jarno
 
Default armelfp: new architecture name for an armel variant

On Thu, Jul 15, 2010 at 08:06:42PM +0300, Konstantinos Margaritis wrote:
> On Thursday 15 July 2010 19:48:43 Aurelien Jarno wrote:
> > Note that the new alternative to hwcap is called "multiarch" in the GNU
> > libc (something totally different than "multiarch" in Debian). It allows
> > to provide different versions of a given symbol using an IFUNC symbol
> > type. This will be resolved by the dynamic loader during relocation
> > depending on the hardware characteristics.
> >
> > This avoid building multiple version of the same software (but still
> > multiple versions of a given function), and to introduce more
> > granularity (e.g. on x86 SSE, SSE2, SSE3, SSSE4.2, AVX, etc).
>
> So, in essence an application/library can include in the same binary multiple
> versions of the same function and the system picks one depending on the
> current cpu capabilities? So things like autodetecting SSE/Altivec, etc are
> not needed anymore?

For libraries sure. I think it might be possible to also get it working
for binaries, though I haven't looked more in details.

Note that you need a recent toolchain for that (binutils and glibc).

> > Currently only x86, x86_64, ia64, powerpc and sparc are supported, but
> > it should not be difficult to add support for more architectures.
>
> I'm interested in that, is it documented somewhere? ( I know the old hwcap was
> not at all, unless one wanted to read half of glibc source code).
>

I am afraid there are not a lot of documentation, beside the glibc
source code. This patch can be interesting though:

http://old.nabble.com/indirect-function-support-td28576476.html

--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100715174325.GT18814@hall.aurel32.net">http://lists.debian.org/20100715174325.GT18814@hall.aurel32.net
 
Old 07-15-2010, 06:06 PM
Paul Brook
 
Default armelfp: new architecture name for an armel variant

> On Thursday 15 July 2010 19:48:43 Aurelien Jarno wrote:
> > Note that the new alternative to hwcap is called "multiarch" in the GNU
> > libc (something totally different than "multiarch" in Debian). It allows
> > to provide different versions of a given symbol using an IFUNC symbol
> > type. This will be resolved by the dynamic loader during relocation
> > depending on the hardware characteristics.
> >
> > This avoid building multiple version of the same software (but still
> > multiple versions of a given function), and to introduce more
> > granularity (e.g. on x86 SSE, SSE2, SSE3, SSSE4.2, AVX, etc).
>
> So, in essence an application/library can include in the same binary
> multiple versions of the same function and the system picks one depending
> on the current cpu capabilities? So things like autodetecting SSE/Altivec,
> etc are not needed anymore?

Not quite. It provides a mechanism for selecting different routines without
the runtime overhead of a check on every call. It effecitvely provides a hook
into the dynamaic linker that allows you to decide which function to export
for a particular symbol. A typical example is to select CPU specific
implementations of memcpy. You still need to supply all the different
implementations, and a function to determine which to use.

All the implementations must use the same ABI.

Paul


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201007151906.52610.paul@codesourcery.com">http://lists.debian.org/201007151906.52610.paul@codesourcery.com
 
Old 07-15-2010, 06:18 PM
Konstantinos Margaritis
 
Default armelfp: new architecture name for an armel variant

On Thursday 15 July 2010 21:06:52 Paul Brook wrote:
> Not quite. It provides a mechanism for selecting different routines without
> the runtime overhead of a check on every call. It effecitvely provides a
> hook into the dynamaic linker that allows you to decide which function to
> export for a particular symbol. A typical example is to select CPU
> specific implementations of memcpy. You still need to supply all the
> different implementations, and a function to determine which to use.

Er, of course I'd have to supply all the implementations, the difference is
that there is now a proper and common way to do it -anyone who's checked
xine/mplayer/vlc source will know what I mean. Still, it's very good news that
something like this has -at last- been implemented.

> All the implementations must use the same ABI.

Of course. I totally understand that this is not a way to keep softfp/hardfp
versions in the same binary.

Konstantinos


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201007152118.56343.markos@genesi-usa.com">http://lists.debian.org/201007152118.56343.markos@genesi-usa.com
 
Old 07-15-2010, 06:35 PM
Loc Minier
 
Default armelfp: new architecture name for an armel variant

On Thu, Jul 15, 2010, Aurelien Jarno wrote:
> It allows
> to provide different versions of a given symbol using an IFUNC symbol
> type. This will be resolved by the dynamic loader during relocation
> depending on the hardware characteristics.
[...]
> Currently only x86, x86_64, ia64, powerpc and sparc are supported, but
> it should not be difficult to add support for more architectures.

Unfortunately, this requires getting it in the ARM ABI spec first, and
apparently that can take very long, they avoid rev-ing the ABI too
frequently (Linaro intends to work on this later this year [1])


[1]
https://blueprints.launchpad.net/binutils-linaro/+spec/stt-gnu-ifunc
and
https://blueprints.launchpad.net/binutils-linaro/+spec/gold-stt-gnu-ifunc
--
Loc Minier


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100715183524.GA6962@bee.dooz.org">http://lists.debian.org/20100715183524.GA6962@bee.dooz.org
 
Old 07-16-2010, 12:37 AM
Hector Oron
 
Default armelfp: new architecture name for an armel variant

Dear developers,

2010/7/13, Riku Voipio <riku.voipio@iki.fi>:
> Subarchs could also be useful if we wanted to build softfp abi compatible
> armv6/armv7 armel builds of the whole debian repository. Of course we could
> do
> builds without subarchs, but then users would be unable distinguish which
> installed packages are for which cpu, and providing that via debian infra
> would not be possible.

Having ABI support in dpkg (already discussed on 'armel' port) could
had been helpful, indeed, as all the upcoming differences between
processors, could make much sense. But is it worth the extra burden of
having to implement such support, arriving to consensus and do the
needed changes in the archive as well as deal with dependency solvers?

Back the, when, at Extremadura [1], when 'armel' was picked up as
new architecture, was said that "in Debian a new ABI is a new
architecture". Could we have been wrong and should we had instead
tried to add ABI field to then control file?

Would you, dpkg maintainers, think that it is worth to go through the
extra hassle of adding such field without having an implementation,
having to change the archive, dependency solvers and achive a
consensus among the rest of the community? Might be the right way for
long term support (which does not mean it has to happen now).

[1] http://wiki.debian.org/DebianEmbeddedWorkSessionExtremadura2006

Best Regards,
--
Hctor Orn

"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTikEReIdZmsVJqdJRQxZRFc2rc4GPxoYFINVSyW9@mail .gmail.com">http://lists.debian.org/AANLkTikEReIdZmsVJqdJRQxZRFc2rc4GPxoYFINVSyW9@mail .gmail.com
 

Thread Tools




All times are GMT. The time now is 06:08 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org