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 @progbits
> > instead.
>
> Wow,
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 for R_x_TPOFF64 relocation
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 overridin
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 space
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 tha
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 kind
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 caus
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
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 does.
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.
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.
It works fine with dynamically linked binaries; and it works fine with
statically-linked PIE binaries; but staticall
14 matches
Mail list logo
