On Thu, Nov 9, 2017 at 12:07 AM, Charles Collicutt
wrote:
> On Wed, Nov 08, 2017 at 10:58:09PM -0800, Philip Guenther wrote:
> > @nobits means the section won't have filespace (where the initialization
> > data is) included in the loaded data. It should work with
On Wed, Nov 08, 2017 at 10:58:09PM -0800, Philip Guenther wrote:
> @nobits means the section won't have filespace (where the initialization
> data is) included in the loaded data. It should work with @progbits
> instead.
Wow, I suck at assembly. However, once again binutils saved me:
$ readelf
On Wed, Nov 8, 2017 at 10:43 PM, Charles Collicutt
wrote:
> On Sun, Nov 05, 2017 at 01:02:36PM -0800, Philip Guenther wrote:
> > Well, ld.so and libc _should_ currently support startup-time TLS using
> the
> > initial-exec and local-exec modules.
>
> I can't see support
On Sun, Nov 05, 2017 at 01:02:36PM -0800, Philip Guenther wrote:
> Well, ld.so and libc _should_ currently support startup-time TLS using the
> initial-exec and local-exec modules.
I can't see support for R_x_TPOFF64 relocations in ld.so(1) so I
don't think initial-exec will work. But local-exec
On Sun, Nov 05, 2017 at 04:17:50PM -0800, Philip Guenther wrote:
> BTW, in the .s file in your original message you had this line:
> .type foo, @object
>
> Since foo is in an SHF_TLS section, it has to be of type STT_TLS.
You're right. But...
> Indeed, binutils is silently
On Mon, 6 Nov 2017, Charles Collicutt wrote:
> On Sun, Nov 05, 2017 at 01:02:36PM -0800, Philip Guenther wrote:
> > The problem with static non-PIE executables is that we don't pass an AUX
> > vector to such processes, so the startup code can't find the TLS segment
> > and doesn't leave any
On Sun, Nov 05, 2017 at 01:02:36PM -0800, Philip Guenther wrote:
> The problem with static non-PIE executables is that we don't pass an AUX
> vector to such processes, so the startup code can't find the TLS segment
> and doesn't leave any space for it.
Ah, thank you.
> The diff below fixes
On Sun, 5 Nov 2017, Stuart Henderson wrote:
> On 2017/11/05 21:08, Charles Collicutt wrote:
> > Hello,
> >
> > I have a program that uses Thread-Local Storage (TLS) with the 'Local Exec'
> > access model [1] on AMD64. This looks like it should work on OpenBSD and,
> > indeed, it mostly does.
>
>
The only "tls" support we have that's currently working is emulated tls,
as exemplified by both clang and the gcc 4.9 port.
See /usr/src/lib/libcompiler_rt/emutls.c
for how it works. It's not incredibly fast, but it does the job...
Fortunately, the gcc and clang people managed to make some
On Mon, Nov 06, 2017 at 12:58:18AM +0200, Paul Irofti wrote:
> We are missing dlopen-time TLS, dynamic TLS relocations and
> thread storage-specifier support.
Thanks. None of those things are needed for the Local Exec access model though,
so that should be OK.
Do you have any idea what might
On Sun, Nov 05, 2017 at 10:51:41PM +, Charles Collicutt wrote:
> On Sun, Nov 05, 2017 at 10:15:57PM +, Stuart Henderson wrote:
> > On 2017/11/05 21:08, Charles Collicutt wrote:
> > > I have a program that uses Thread-Local Storage (TLS) with the 'Local
> > > Exec'
> > > access model [1]
On Sun, Nov 05, 2017 at 10:15:57PM +, Stuart Henderson wrote:
> On 2017/11/05 21:08, Charles Collicutt wrote:
> > I have a program that uses Thread-Local Storage (TLS) with the 'Local Exec'
> > access model [1] on AMD64. This looks like it should work on OpenBSD and,
> > indeed, it mostly
On 2017/11/05 21:08, Charles Collicutt wrote:
> Hello,
>
> I have a program that uses Thread-Local Storage (TLS) with the 'Local Exec'
> access model [1] on AMD64. This looks like it should work on OpenBSD and,
> indeed, it mostly does.
OpenBSD doesn't have real thread-local storage yet.
13 matches
Mail list logo