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 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 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 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: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,
&
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
On 14 June 2017 at 19:22, Ted Unangst wrote:
> Charles Collicutt wrote:
> > That works, thank you. gcc-local(1) only mentions -nopie as an option for
> > the linker, so I thought it ought to be passed with -Wl,...
>
> I think I would interpret that sentence to mean linker as
On 14 June 2017 at 17:34, Ted Unangst wrote:
> gcc -static -nopie -o foo foo.c
>
That works, thank you. gcc-local(1) only mentions -nopie as an option for
the linker, so I thought it ought to be passed with -Wl,...
So passing -nopie to gcc both causes it to link against the correct crt0
and als
Hi,
Is the following expected behaviour?
$ gcc -static -Wl,-nopie -Wl,-v -o foo foo.c
collect2 version 4.2.1 20070719 (OpenBSD/x86-64 ELF)
/usr/bin/ld -e __start -Bstatic -dynamic-linker /usr/libexec/ld.so -o foo
/usr/lib/rcrt0.o /usr/lib/crtbegin.o
-L/usr/lib/gcc-lib/amd64-unknown-openbsd6.1/4
10 matches
Mail list logo
