* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
0 siblings, 1 reply; 34+ messages in thread
From: Michael Matz @ 2016-01-01 0:00 UTC (permalink / raw)
To: H.J. Lu; +Cc: Alan Modra, gnu-gabi
Hi,
On Tue, 23 Feb 2016, H.J. Lu wrote:
> Not only we need to change defined weak symbol behavior, we also need to
> change undefined non-weak symbol behavior when taking its address.
Why? An undefined non-weak symbol reference leads to a linker error,
done. Why change that?
Ciao,
Michael.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
1 sibling, 0 replies; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: gnu-gabi
On Mon, Feb 22, 2016 at 9:45 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Feb 22, 2016 at 8:25 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> Currently when building executable, undefined weak symbol is resolved
>> differently, depending on if the relocatable input is compiled with PIC or
>> not:
>>
>> hjl@gnu-tools-1 weak-1]$ cat x.c
>> extern void __attribute__ ((weak)) fun (void);
>> int main (void)
>> {
>> if (&fun != 0)
>> fun ();
>> return 0;
>> }
>> [hjl@gnu-tools-1 weak-1]$ make
>> gcc -B./ -O2 -o x x.c
>> gcc -B./ -O2 -o y x.c -fPIC
>> readelf -r x
>>
>> Relocation section '.rela.dyn' at offset 0x328 contains 1 entries:
>> Offset Info Type Sym. Value Sym. Name + Addend
>> 000000600870 000200000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0
>>
>> Relocation section '.rela.plt' at offset 0x340 contains 1 entries:
>> Offset Info Type Sym. Value Sym. Name + Addend
>> 000000600890 000100000007 R_X86_64_JUMP_SLO 0000000000000000
>> __libc_start_main@GLIBC_2.2.5 + 0
>>
>> There is no dynamic relocation against fun, whose value is
>> resolved to zero at link-time.
>>
>> readelf -r y
>>
>> Relocation section '.rela.dyn' at offset 0x348 contains 2 entries:
>> Offset Info Type Sym. Value Sym. Name + Addend
>> 0000006008a0 000100000006 R_X86_64_GLOB_DAT 0000000000000000 fun + 0
>> 0000006008a8 000300000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0
>>
>> Relocation section '.rela.plt' at offset 0x378 contains 1 entries:
>> Offset Info Type Sym. Value Sym. Name + Addend
>> 0000006008c8 000200000007 R_X86_64_JUMP_SLO 0000000000000000
>> __libc_start_main@GLIBC_2.2.5 + 0
>> [hjl@gnu-tools-1 weak-1]$
>>
>> There is dynamic relocation against fun, whose value is resolved
>> at runt-time. We should make it consistent, regardless if input
>> relocatable file is compiled with PIC or not.
>>
>> I raised the issue at gABI:
>>
>> https://groups.google.com/d/msg/generic-abi/Ckq19PfLxyk/eCbXPofkAQAJ
>>
>> But if gABI change is incompatible with other OSes, we need to
>> specify it in GNU ABI.
>
> We should extend GNU ABI to:
>
> When creating executable, if dynamic relocation is available at
> run-time, the link
> editor should generate dynamic relocations against unresolved weak symbols so
> that their values will be resolved at run-time.
>
I opened:
https://sourceware.org/bugzilla/show_bug.cgi?id=19704
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` Alan Modra
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
1 sibling, 1 reply; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: Alan Modra; +Cc: Michael Matz, gnu-gabi
On Mon, Feb 22, 2016 at 8:40 PM, Alan Modra <amodra@gmail.com> wrote:
> On Mon, Feb 22, 2016 at 02:43:55PM -0800, H.J. Lu wrote:
>> we create executable with dynamic R_X86_64_32 relocation against
>> fun .text section, which leads to DT_TEXTREL. Is this what we want?
>
> I think that avoiding DT_TEXTREL is historically why we haven't
> supported weak symbols well in non-PIC executables. Another closely
> related issue is the old hack written into most ABIs that the address
> of a function referenced in an executable and defined in a shared
> library is the address of that function's PLT code in the executable.
>
> Note that this affects both defined and undefined weak functions in
> non-PIC executables. Currently, if we find a definition for "fun" at
> link time in a shared library, "&fun" is the PLT entry in the
> executable and "if (&fun)" effectively becomes "if (1)". So if you
> link the executable with a shared library containing a definition of
> "fun" but at run-time load a newer shared library *not* defining "fun",
> your program will segfault.
>
> Therefore, if the aim is to make PIC and non-PIC executables behave
> the same you need to change defined weak symbol behaviour too. Any
> non-PIC executable that takes the address of a weak function in code
> or rodata would become DT_TEXTREL.
>
Not only we need to change defined weak symbol behavior, we
also need to change undefined non-weak symbol behavior when
taking its address. We need to generate PIC-like code to take
address of a symbol in non-PIC text section. Is this what we
want?
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` Alan Modra
@ 2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
1 sibling, 1 reply; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: Alan Modra; +Cc: Michael Matz, gnu-gabi
On Mon, Feb 22, 2016 at 8:40 PM, Alan Modra <amodra@gmail.com> wrote:
>
> However, that might be a bad idea. Lots of C++ code uses weak symbols
> for functions defined in header files, and other objects with vague
> linkage. These result in weak definitions in eg. libstdc++.so. I'm
> not sure how many executables take the address of such functions and
> thus might become DT_TEXTREL.
Most, if not all, of programs will have DT_TEXTREL on x86 if undefined
weak symbols require dynamic relocations.
--
H.J.
---
[hjl@gnu-4 ~]$ objdump -dwr /usr/lib/gcc/x86_64-redhat-linux/5.3.1/crtbegin.o
/usr/lib/gcc/x86_64-redhat-linux/5.3.1/crtbegin.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <deregister_tm_clones>:
0: b8 00 00 00 00 mov $0x0,%eax 1: R_X86_64_32 __TMC_END__+0x7
5: 55 push %rbp
6: 48 2d 00 00 00 00 sub $0x0,%rax 8: R_X86_64_32S .tm_clone_table
c: 48 83 f8 0e cmp $0xe,%rax
10: 48 89 e5 mov %rsp,%rbp
13: 76 1b jbe 30 <deregister_tm_clones+0x30>
15: b8 00 00 00 00 mov $0x0,%eax 16: R_X86_64_32
_ITM_deregisterTMCloneTable
1a: 48 85 c0 test %rax,%rax
1d: 74 11 je 30 <deregister_tm_clones+0x30>
1f: 5d pop %rbp
20: bf 00 00 00 00 mov $0x0,%edi 21: R_X86_64_32 .tm_clone_table
25: ff e0 jmpq *%rax
27: 66 0f 1f 84 00 00 00 00 00 nopw 0x0(%rax,%rax,1)
30: 5d pop %rbp
31: c3 retq
32: 0f 1f 40 00 nopl 0x0(%rax)
36: 66 2e 0f 1f 84 00 00 00 00 00 nopw %cs:0x0(%rax,%rax,1)
0000000000000040 <register_tm_clones>:
40: be 00 00 00 00 mov $0x0,%esi 41: R_X86_64_32 __TMC_END__
45: 55 push %rbp
46: 48 81 ee 00 00 00 00 sub $0x0,%rsi 49: R_X86_64_32S .tm_clone_table
4d: 48 c1 fe 03 sar $0x3,%rsi
51: 48 89 e5 mov %rsp,%rbp
54: 48 89 f0 mov %rsi,%rax
57: 48 c1 e8 3f shr $0x3f,%rax
5b: 48 01 c6 add %rax,%rsi
5e: 48 d1 fe sar %rsi
61: 74 15 je 78 <register_tm_clones+0x38>
63: b8 00 00 00 00 mov $0x0,%eax 64: R_X86_64_32
_ITM_registerTMCloneTable
68: 48 85 c0 test %rax,%rax
6b: 74 0b je 78 <register_tm_clones+0x38>
6d: 5d pop %rbp
6e: bf 00 00 00 00 mov $0x0,%edi 6f: R_X86_64_32 .tm_clone_table
73: ff e0 jmpq *%rax
75: 0f 1f 00 nopl (%rax)
78: 5d pop %rbp
79: c3 retq
7a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
0000000000000080 <__do_global_dtors_aux>:
80: 80 3d 00 00 00 00 00 cmpb $0x0,0x0(%rip) # 87
<__do_global_dtors_aux+0x7> 82: R_X86_64_PC32 .bss-0x5
87: 75 11 jne 9a <__do_global_dtors_aux+0x1a>
89: 55 push %rbp
8a: 48 89 e5 mov %rsp,%rbp
8d: e8 6e ff ff ff callq 0 <deregister_tm_clones>
92: 5d pop %rbp
93: c6 05 00 00 00 00 01 movb $0x1,0x0(%rip) # 9a
<__do_global_dtors_aux+0x1a> 95: R_X86_64_PC32 .bss-0x5
9a: f3 c3 repz retq
9c: 0f 1f 40 00 nopl 0x0(%rax)
00000000000000a0 <frame_dummy>:
a0: bf 00 00 00 00 mov $0x0,%edi a1: R_X86_64_32 .jcr
a5: 48 83 3f 00 cmpq $0x0,(%rdi)
a9: 75 05 jne b0 <frame_dummy+0x10>
ab: eb 93 jmp 40 <register_tm_clones>
ad: 0f 1f 00 nopl (%rax)
b0: b8 00 00 00 00 mov $0x0,%eax b1: R_X86_64_32 _Jv_RegisterClasses
b5: 48 85 c0 test %rax,%rax
b8: 74 f1 je ab <frame_dummy+0xb>
ba: 55 push %rbp
bb: 48 89 e5 mov %rsp,%rbp
be: ff d0 callq *%rax
c0: 5d pop %rbp
c1: e9 7a ff ff ff jmpq 40 <register_tm_clones>
[hjl@gnu-4 ~]$ readelf -sW
/usr/lib/gcc/x86_64-redhat-linux/5.3.1/crtbegin.o | grep WEAK
23: 0000000000000000 0 NOTYPE WEAK DEFAULT UND
_ITM_deregisterTMCloneTable
24: 0000000000000000 0 NOTYPE WEAK DEFAULT UND
_ITM_registerTMCloneTable
26: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
[hjl@gnu-4 ~]$
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
0 siblings, 1 reply; 34+ messages in thread
From: Michael Matz @ 2016-01-01 0:00 UTC (permalink / raw)
To: H.J. Lu; +Cc: Alan Modra, gnu-gabi
Hi,
On Tue, 23 Feb 2016, H.J. Lu wrote:
> On Mon, Feb 22, 2016 at 8:40 PM, Alan Modra <amodra@gmail.com> wrote:
> >
> > However, that might be a bad idea. Lots of C++ code uses weak symbols
> > for functions defined in header files, and other objects with vague
> > linkage. These result in weak definitions in eg. libstdc++.so. I'm
> > not sure how many executables take the address of such functions and
> > thus might become DT_TEXTREL.
>
> Most, if not all, of programs will have DT_TEXTREL on x86 if undefined
> weak symbols require dynamic relocations.
Hmm, that's less than ideal of course. Well, if the goal is to make PIC
and non-PIC the same, we could also go the opposite way: make PIC behave
like non-PIC, i.e. resolve weak symbols always at link editing time. That
of course would remove features (can't change libs at runtime anymore, if
they change in definedness of such a symbol).
Or, a third variant: change the compiler to emit PIC like code for taking
addresses of weak symbols also in generally non-PIC code, so we could
avoid TEXTREL.
I think the ideal solution would be that last one, change link editor now
to behave like with PIC code, and eventually fix the compiler to not have
to generate TEXTREL.
Note that the existence of DT_TEXTREL itself isn't that bad: only those
pages that actually contain relocations will be unshared, so for the
example of crtbegin.o it's only one page per process. In addition
crtbegin could of course always be PIC code, avoiding the issue.
I've looked at a normal c++ program (zypper) and the only weak undef
symbols are those from crtbegin. There are many other weak symbols, but
they are defined in the executable itself (it's mostly template
instantiations), so pose no problem.
Ciao,
Michael.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 Specify how undefined weak symbol should be resolved in executable H.J. Lu
@ 2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
0 siblings, 2 replies; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: gnu-gabi
On Mon, Feb 22, 2016 at 8:25 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> Currently when building executable, undefined weak symbol is resolved
> differently, depending on if the relocatable input is compiled with PIC or
> not:
>
> hjl@gnu-tools-1 weak-1]$ cat x.c
> extern void __attribute__ ((weak)) fun (void);
> int main (void)
> {
> if (&fun != 0)
> fun ();
> return 0;
> }
> [hjl@gnu-tools-1 weak-1]$ make
> gcc -B./ -O2 -o x x.c
> gcc -B./ -O2 -o y x.c -fPIC
> readelf -r x
>
> Relocation section '.rela.dyn' at offset 0x328 contains 1 entries:
> Offset Info Type Sym. Value Sym. Name + Addend
> 000000600870 000200000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0
>
> Relocation section '.rela.plt' at offset 0x340 contains 1 entries:
> Offset Info Type Sym. Value Sym. Name + Addend
> 000000600890 000100000007 R_X86_64_JUMP_SLO 0000000000000000
> __libc_start_main@GLIBC_2.2.5 + 0
>
> There is no dynamic relocation against fun, whose value is
> resolved to zero at link-time.
>
> readelf -r y
>
> Relocation section '.rela.dyn' at offset 0x348 contains 2 entries:
> Offset Info Type Sym. Value Sym. Name + Addend
> 0000006008a0 000100000006 R_X86_64_GLOB_DAT 0000000000000000 fun + 0
> 0000006008a8 000300000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0
>
> Relocation section '.rela.plt' at offset 0x378 contains 1 entries:
> Offset Info Type Sym. Value Sym. Name + Addend
> 0000006008c8 000200000007 R_X86_64_JUMP_SLO 0000000000000000
> __libc_start_main@GLIBC_2.2.5 + 0
> [hjl@gnu-tools-1 weak-1]$
>
> There is dynamic relocation against fun, whose value is resolved
> at runt-time. We should make it consistent, regardless if input
> relocatable file is compiled with PIC or not.
>
> I raised the issue at gABI:
>
> https://groups.google.com/d/msg/generic-abi/Ckq19PfLxyk/eCbXPofkAQAJ
>
> But if gABI change is incompatible with other OSes, we need to
> specify it in GNU ABI.
We should extend GNU ABI to:
When creating executable, if dynamic relocation is available at
run-time, the link
editor should generate dynamic relocations against unresolved weak symbols so
that their values will be resolved at run-time.
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Alan Modra
@ 2016-01-01 0:00 ` H.J. Lu
1 sibling, 0 replies; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: Michael Matz; +Cc: Alan Modra, gnu-gabi
On Tue, Feb 23, 2016 at 9:10 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, Feb 23, 2016 at 9:01 AM, Michael Matz <matz@suse.de> wrote:
>> Hi,
>>
>> On Tue, 23 Feb 2016, H.J. Lu wrote:
>>
>>> >> Not only we need to change defined weak symbol behavior, we also need
>>> >> to change undefined non-weak symbol behavior when taking its address.
>>> >
>>> > Why? An undefined non-weak symbol reference leads to a linker error,
>>> > done. Why change that?
>>>
>>> Make it "external non-weak symbol", which is a symbol defined in a
>>> shared object.
>>
>> What would you like to change in behaviour for them (and why must it be
>> done at the same time as changing something for weak symbols)? A
>> reference to the address of such a function symbol from an executable
>> resolves to the plt slot currently (which in turn is exported, so that
>> address references from other modules resolve to the same). A reference
>> to a non-function symbol is loaded from the got. In all cases must this
>> symbol be defined somewhere (otherwise linker error), so I don't see what
>> we need to change, nor why that would force DT_TEXTREL (or the compiler to
>> emit PIC like code).
>>
>
> At run-time, there is no difference between weak defined and non-weak
> defined symbols. If we change defined weak symbol behavior, we also
> need to change defined non-weak symbol behavior.
>
I will check this patch:
https://sourceware.org/ml/binutils/2016-02/msg00339.html
into binutils master branch to make behaviors of static executable,
dynamic executable and position independent executable consistent with
references to undefined weak and defined symbols, regardless if the
relocatable input is compiled with PIC or not.
I created users/hjl/pr19704 branch to treat undefined weak symbol in
the executable as dynamic, requiring dynamic relocation, on x86 via
a command line switch:
-z dynamic-undefined-weak Treat undefined weak symbol as dynamic
We need to fully investigate its implications before moving forward
with it.
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
0 siblings, 1 reply; 34+ messages in thread
From: Michael Matz @ 2016-01-01 0:00 UTC (permalink / raw)
To: H.J. Lu; +Cc: Carlos O'Donell, Alan Modra, gnu-gabi
Hi,
On Wed, 24 Feb 2016, H.J. Lu wrote:
> > Agreed. Anything that brings back weak symbols into the dynamic loader
> > is going to be highly suspect to me, and require a lot of explaining.
>
> I was saying as far as ld was concerned, weak defined and non-weak
> defined dynamic symbols would be treated equally at run-time. Do you
> agree with me?
I at least don't. The difference is that a defined weak symbol (at link
edit time) might become undefined at runtime. A defined non-weak symbol
can't. So they have to be handled differently.
Ciao,
Michael.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` H.J. Lu
0 siblings, 0 replies; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: Michael Matz; +Cc: gnu-gabi
On Mon, Feb 22, 2016 at 2:47 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Feb 22, 2016 at 2:43 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Mon, Feb 22, 2016 at 10:28 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Mon, Feb 22, 2016 at 10:17 AM, Michael Matz <matz@suse.de> wrote:
>>>> Hi,
>>>>
>>>> On Mon, 22 Feb 2016, H.J. Lu wrote:
>>>>
>>>>> > Typo? What is the meaning of "dynamic relocation available at
>>>>> > runtime". Are you talking about a relocation entry or the relocation
>>>>> > process?
>>>>>
>>>>> Dynamic relocation isn't available with static linking.
>>>>
>>>> So you _are_ talking about the process. I think it's customary to call
>>>> such executables "dynamic", or perhaps non-static, isn't it? (Why I'm
>>>> confused with your wording: a dynamic executable which happens to have no
>>>> dynamic reloc entries, has "no dynamic relocation available at runtime",
>>>> and so we couldn't add one :))
>>>>
>>>>> > How about "When creating a dynamic executable the link editor should
>>>>> > ..."?
>>>>
>>>> So, I still can understand my version better (possibly with
>>>> s/dynamic/non-static/) :)
>>>>
>>>
>>> Let's go with:
>>>
>>> When creating dynamic executable, the link editor should generate dynamic
>>> relocations against unresolved weak symbols so that their values will be
>>> resolved at run-time.
>>>
>>
>> Second thought. To generate dynamic relocation for R_X86_64_32
>> against fun in:
>>
>> [hjl@gnu-6 pr19704]$ objdump -dwr foo.o
>>
>> foo.o: file format elf64-x86-64
>>
>>
>> Disassembly of section .text.startup:
>>
>> 0000000000000000 <main>:
>> 0: b8 00 00 00 00 mov $0x0,%eax 1: R_X86_64_32 fun
>> 5: 48 85 c0 test %rax,%rax
>> 8: 74 10 je 1a <main+0x1a>
>> a: 48 83 ec 08 sub $0x8,%rsp
>> e: e8 00 00 00 00 callq 13 <main+0x13> f: R_X86_64_PC32 fun-0x4
>> 13: 31 c0 xor %eax,%eax
>> 15: 48 83 c4 08 add $0x8,%rsp
>> 19: c3 retq
>> 1a: 31 c0 xor %eax,%eax
>> 1c: c3 retq
>> [hjl@gnu-6 pr19704]$
>>
>> we create executable with dynamic R_X86_64_32 relocation against
>> fun .text section, which leads to DT_TEXTREL. Is this what we want?
>>
>
> I believe the intention of undefined weak symbol is it should be resolved
> at link-time when creating executable, dynamic or static.
There is discrepancy between PIC input and non-PIC input on x86.
There may be a discrepancy between x86, where PIC is off by default,
and the target, where PIC is always on. If we can't get an agreement
among Linux targets, we should address it in x86 psABI.
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Alan Modra
1 sibling, 1 reply; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: Michael Matz; +Cc: gnu-gabi
On Mon, Feb 22, 2016 at 2:43 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Feb 22, 2016 at 10:28 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Mon, Feb 22, 2016 at 10:17 AM, Michael Matz <matz@suse.de> wrote:
>>> Hi,
>>>
>>> On Mon, 22 Feb 2016, H.J. Lu wrote:
>>>
>>>> > Typo? What is the meaning of "dynamic relocation available at
>>>> > runtime". Are you talking about a relocation entry or the relocation
>>>> > process?
>>>>
>>>> Dynamic relocation isn't available with static linking.
>>>
>>> So you _are_ talking about the process. I think it's customary to call
>>> such executables "dynamic", or perhaps non-static, isn't it? (Why I'm
>>> confused with your wording: a dynamic executable which happens to have no
>>> dynamic reloc entries, has "no dynamic relocation available at runtime",
>>> and so we couldn't add one :))
>>>
>>>> > How about "When creating a dynamic executable the link editor should
>>>> > ..."?
>>>
>>> So, I still can understand my version better (possibly with
>>> s/dynamic/non-static/) :)
>>>
>>
>> Let's go with:
>>
>> When creating dynamic executable, the link editor should generate dynamic
>> relocations against unresolved weak symbols so that their values will be
>> resolved at run-time.
>>
>
> Second thought. To generate dynamic relocation for R_X86_64_32
> against fun in:
>
> [hjl@gnu-6 pr19704]$ objdump -dwr foo.o
>
> foo.o: file format elf64-x86-64
>
>
> Disassembly of section .text.startup:
>
> 0000000000000000 <main>:
> 0: b8 00 00 00 00 mov $0x0,%eax 1: R_X86_64_32 fun
> 5: 48 85 c0 test %rax,%rax
> 8: 74 10 je 1a <main+0x1a>
> a: 48 83 ec 08 sub $0x8,%rsp
> e: e8 00 00 00 00 callq 13 <main+0x13> f: R_X86_64_PC32 fun-0x4
> 13: 31 c0 xor %eax,%eax
> 15: 48 83 c4 08 add $0x8,%rsp
> 19: c3 retq
> 1a: 31 c0 xor %eax,%eax
> 1c: c3 retq
> [hjl@gnu-6 pr19704]$
>
> we create executable with dynamic R_X86_64_32 relocation against
> fun .text section, which leads to DT_TEXTREL. Is this what we want?
>
I believe the intention of undefined weak symbol is it should be resolved
at link-time when creating executable, dynamic or static.
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` Michael Matz
@ 2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
0 siblings, 1 reply; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: Michael Matz; +Cc: Carlos O'Donell, Alan Modra, gnu-gabi
On Wed, Feb 24, 2016 at 7:30 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Wed, 24 Feb 2016, H.J. Lu wrote:
>
>> > Agreed. Anything that brings back weak symbols into the dynamic loader
>> > is going to be highly suspect to me, and require a lot of explaining.
>>
>> I was saying as far as ld was concerned, weak defined and non-weak
>> defined dynamic symbols would be treated equally at run-time. Do you
>> agree with me?
>
> I at least don't. The difference is that a defined weak symbol (at link
> edit time) might become undefined at runtime. A defined non-weak symbol
> can't. So they have to be handled differently.
>
How?
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` Michael Matz
@ 2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Alan Modra
2016-01-01 0:00 ` H.J. Lu
0 siblings, 2 replies; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: Michael Matz; +Cc: Alan Modra, gnu-gabi
On Tue, Feb 23, 2016 at 9:01 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 23 Feb 2016, H.J. Lu wrote:
>
>> >> Not only we need to change defined weak symbol behavior, we also need
>> >> to change undefined non-weak symbol behavior when taking its address.
>> >
>> > Why? An undefined non-weak symbol reference leads to a linker error,
>> > done. Why change that?
>>
>> Make it "external non-weak symbol", which is a symbol defined in a
>> shared object.
>
> What would you like to change in behaviour for them (and why must it be
> done at the same time as changing something for weak symbols)? A
> reference to the address of such a function symbol from an executable
> resolves to the plt slot currently (which in turn is exported, so that
> address references from other modules resolve to the same). A reference
> to a non-function symbol is loaded from the got. In all cases must this
> symbol be defined somewhere (otherwise linker error), so I don't see what
> we need to change, nor why that would force DT_TEXTREL (or the compiler to
> emit PIC like code).
>
At run-time, there is no difference between weak defined and non-weak
defined symbols. If we change defined weak symbol behavior, we also
need to change defined non-weak symbol behavior.
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` Michael Matz
@ 2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
0 siblings, 1 reply; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: Michael Matz; +Cc: gnu-gabi
On Mon, Feb 22, 2016 at 10:11 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Mon, 22 Feb 2016, H.J. Lu wrote:
>
>> We should extend GNU ABI to:
>>
>> When creating executable, if dynamic relocation is available at
>> run-time,
>
> Typo? What is the meaning of "dynamic relocation available at runtime".
> Are you talking about a relocation entry or the relocation process?
Dynamic relocation isn't available with static linking.
> How about "When creating a dynamic executable the link editor should ..."?
>
>> the link editor should generate dynamic relocations against
>> unresolved weak symbols so that their values will be resolved at
>> run-time.
>
>
> Ciao,
> Michael.
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` Michael Matz
@ 2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
0 siblings, 1 reply; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: Michael Matz; +Cc: Alan Modra, gnu-gabi
On Tue, Feb 23, 2016 at 8:49 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 23 Feb 2016, H.J. Lu wrote:
>
>> Not only we need to change defined weak symbol behavior, we also need to
>> change undefined non-weak symbol behavior when taking its address.
>
> Why? An undefined non-weak symbol reference leads to a linker error,
> done. Why change that?
>
Make it "external non-weak symbol", which is a symbol defined in
a shared object.
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` Alan Modra
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
1 sibling, 2 replies; 34+ messages in thread
From: Alan Modra @ 2016-01-01 0:00 UTC (permalink / raw)
To: H.J. Lu; +Cc: Michael Matz, gnu-gabi
On Mon, Feb 22, 2016 at 02:43:55PM -0800, H.J. Lu wrote:
> we create executable with dynamic R_X86_64_32 relocation against
> fun .text section, which leads to DT_TEXTREL. Is this what we want?
I think that avoiding DT_TEXTREL is historically why we haven't
supported weak symbols well in non-PIC executables. Another closely
related issue is the old hack written into most ABIs that the address
of a function referenced in an executable and defined in a shared
library is the address of that function's PLT code in the executable.
Note that this affects both defined and undefined weak functions in
non-PIC executables. Currently, if we find a definition for "fun" at
link time in a shared library, "&fun" is the PLT entry in the
executable and "if (&fun)" effectively becomes "if (1)". So if you
link the executable with a shared library containing a definition of
"fun" but at run-time load a newer shared library *not* defining "fun",
your program will segfault.
Therefore, if the aim is to make PIC and non-PIC executables behave
the same you need to change defined weak symbol behaviour too. Any
non-PIC executable that takes the address of a weak function in code
or rodata would become DT_TEXTREL.
However, that might be a bad idea. Lots of C++ code uses weak symbols
for functions defined in header files, and other objects with vague
linkage. These result in weak definitions in eg. libstdc++.so. I'm
not sure how many executables take the address of such functions and
thus might become DT_TEXTREL.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` Michael Matz
@ 2016-01-01 0:00 ` Szabolcs Nagy
2016-01-01 0:00 ` Michael Matz
0 siblings, 1 reply; 34+ messages in thread
From: Szabolcs Nagy @ 2016-01-01 0:00 UTC (permalink / raw)
To: Michael Matz; +Cc: H.J. Lu, Alan Modra, gnu-gabi
* Michael Matz <matz@suse.de> [2016-02-23 16:16:15 +0100]:
> On Tue, 23 Feb 2016, H.J. Lu wrote:
> > I checked cc1plus and found:
> >
> > [hjl@gnu-6 5.3.1]$ readelf -sW cc1plus| grep WEAK | grep UND
>
> Careful, that includes .symtab, not only .dynsym. These are the .dynsyms:
>
> > 33: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_signal@GLIBC_2.3.2 (3)
> > 2924: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_broadcast@GLIBC_2.3.2 (3)
> > 4861: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_key_create
> > 6330: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_getspecific
> > 7205: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_mutex_unlock@GLIBC_2.2.5 (2)
> > 7719: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_key_delete
> > 9118: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __pthread_key_create
> > 11985: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
> > 12269: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_once
> > 15201: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_mutex_lock@GLIBC_2.2.5 (2)
> > 15794: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_wait@GLIBC_2.3.2 (3)
> > 18312: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterTMCloneTable
> > 19108: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_setspecific
> > 19649: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
> > 19871: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_registerTMCloneTable
> > 20107: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_destroy@GLIBC_2.3.2 (3)
>
> After here it's .symtab:
>
> > 18570: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_signal@@GLIBC_2.3.2
> >
> > Do you know how many of them lead to DT_TEXTREL?
>
> I think all those not going via the PLT, hence looking at the relocs for
> those symbols involved, ignoring JUMP_SLOT relocs will give you that. For
> my cc1plus it's only this:
>
> pthread_cancel
>
> (of those that are undef-weak), and only one reference.
>
libgcc/gthr-posix.h checks 'multi-threadedness' by looking
at a weakref (if it's zero then single-threaded execution
is assumed).
on glibc the weakref is __pthread_key_create nowadays,
but on other systems or older libgcc it's pthread_cancel.
so the address of this weakref is taken, the other pthread
weakrefs are called only if this weakref was non-zero.
i'm not sure how the proposed changes affect this use-case,
but this way of deciding single-threadedness is broken and
a bug that gcc should eventually fix. (e.g. a static linked
multi-threaded c++ application may not have a pthread_cancel
symbol defined and thus libstdc++ may not use locks where
necessary or crash when pthread_cancel is defined but other
weakrefs are not).
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` Alan Modra
2016-01-01 0:00 ` Carlos O'Donell
0 siblings, 1 reply; 34+ messages in thread
From: Alan Modra @ 2016-01-01 0:00 UTC (permalink / raw)
To: H.J. Lu; +Cc: Michael Matz, gnu-gabi
On Tue, Feb 23, 2016 at 05:18:16PM -0800, H.J. Lu wrote:
> On Tue, Feb 23, 2016 at 5:04 PM, Alan Modra <amodra@gmail.com> wrote:
> > On Tue, Feb 23, 2016 at 09:10:51AM -0800, H.J. Lu wrote:
> >> At run-time, there is no difference between weak defined and non-weak
> >> defined symbols.
> >
> > This is not true, and even if it was..
> >
>
> Please do
>
> # git grep dl_dynamic_weak
>
> in glibc to see it for yourself.
That's exactly the code that shows ld.so can treat weak and strong
symbols differently! (And yes, I know the default setting of
dl_dynamic_weak.)
Besides, the main point of my comment was that it is simply faulty
reasoning to claim that the linker needs to change because of some
ld.so behaviour.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
0 siblings, 1 reply; 34+ messages in thread
From: Michael Matz @ 2016-01-01 0:00 UTC (permalink / raw)
To: H.J. Lu; +Cc: Carlos O'Donell, Alan Modra, gnu-gabi
Hi,
On Wed, 24 Feb 2016, H.J. Lu wrote:
> > To not do that (i.e. resolve them always at link edit time) breaks
> > various current uses of weak symbols. We could do that of course, but
> > I don't think that would be useful to users.
>
> I suggest you raise this issue at
>
> https://groups.google.com/forum/#!forum/generic-abi
You want to change existing behaviour, not me. The Solaris and HP-UX guys
already stated what they do, and are unlikely to want to change behaviour.
I don't think we can change the gABI to be more explicit about weak
symbols (not the least because Solaris and HP-UX already differ in the
details), so I think we're left with discussing it here.
Ciao,
Michael.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
0 siblings, 1 reply; 34+ messages in thread
From: Michael Matz @ 2016-01-01 0:00 UTC (permalink / raw)
To: H.J. Lu; +Cc: Alan Modra, gnu-gabi
Hi,
On Tue, 23 Feb 2016, H.J. Lu wrote:
> >> Not only we need to change defined weak symbol behavior, we also need
> >> to change undefined non-weak symbol behavior when taking its address.
> >
> > Why? An undefined non-weak symbol reference leads to a linker error,
> > done. Why change that?
>
> Make it "external non-weak symbol", which is a symbol defined in a
> shared object.
What would you like to change in behaviour for them (and why must it be
done at the same time as changing something for weak symbols)? A
reference to the address of such a function symbol from an executable
resolves to the plt slot currently (which in turn is exported, so that
address references from other modules resolve to the same). A reference
to a non-function symbol is loaded from the got. In all cases must this
symbol be defined somewhere (otherwise linker error), so I don't see what
we need to change, nor why that would force DT_TEXTREL (or the compiler to
emit PIC like code).
Ciao,
Michael.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` Szabolcs Nagy
@ 2016-01-01 0:00 ` Michael Matz
0 siblings, 0 replies; 34+ messages in thread
From: Michael Matz @ 2016-01-01 0:00 UTC (permalink / raw)
To: Szabolcs Nagy; +Cc: H.J. Lu, Alan Modra, gnu-gabi
Hi,
On Tue, 23 Feb 2016, Szabolcs Nagy wrote:
> libgcc/gthr-posix.h checks 'multi-threadedness' by looking
> at a weakref (if it's zero then single-threaded execution
> is assumed).
>
> on glibc the weakref is __pthread_key_create nowadays,
> but on other systems or older libgcc it's pthread_cancel.
Yep, that's the one.
> so the address of this weakref is taken, the other pthread weakrefs are
> called only if this weakref was non-zero.
>
> i'm not sure how the proposed changes affect this use-case,
Some of the variants will make this use-case work also for non-PIC
executables, at the expense of one more unsharable .text page on some
architectures (the one where this adress-checking takes place).
> but this way of deciding single-threadedness is broken and a bug that
> gcc should eventually fix. (e.g. a static linked multi-threaded c++
> application may not have a pthread_cancel symbol defined and thus
> libstdc++ may not use locks where necessary or crash when pthread_cancel
> is defined but other weakrefs are not).
Yep, that's one problem of our current behaviour with addresses of weak
symbols on non-PIC.
Ciao,
Michael.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` Michael Matz
@ 2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
0 siblings, 1 reply; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: Michael Matz; +Cc: gnu-gabi
On Mon, Feb 22, 2016 at 10:17 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Mon, 22 Feb 2016, H.J. Lu wrote:
>
>> > Typo? What is the meaning of "dynamic relocation available at
>> > runtime". Are you talking about a relocation entry or the relocation
>> > process?
>>
>> Dynamic relocation isn't available with static linking.
>
> So you _are_ talking about the process. I think it's customary to call
> such executables "dynamic", or perhaps non-static, isn't it? (Why I'm
> confused with your wording: a dynamic executable which happens to have no
> dynamic reloc entries, has "no dynamic relocation available at runtime",
> and so we couldn't add one :))
>
>> > How about "When creating a dynamic executable the link editor should
>> > ..."?
>
> So, I still can understand my version better (possibly with
> s/dynamic/non-static/) :)
>
Let's go with:
When creating dynamic executable, the link editor should generate dynamic
relocations against unresolved weak symbols so that their values will be
resolved at run-time.
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
1 sibling, 1 reply; 34+ messages in thread
From: Michael Matz @ 2016-01-01 0:00 UTC (permalink / raw)
To: H.J. Lu; +Cc: gnu-gabi
Hi,
On Mon, 22 Feb 2016, H.J. Lu wrote:
> We should extend GNU ABI to:
>
> When creating executable, if dynamic relocation is available at
> run-time,
Typo? What is the meaning of "dynamic relocation available at runtime".
Are you talking about a relocation entry or the relocation process?
How about "When creating a dynamic executable the link editor should ..."?
> the link editor should generate dynamic relocations against
> unresolved weak symbols so that their values will be resolved at
> run-time.
Ciao,
Michael.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
0 siblings, 1 reply; 34+ messages in thread
From: Michael Matz @ 2016-01-01 0:00 UTC (permalink / raw)
To: H.J. Lu; +Cc: gnu-gabi
Hi,
On Mon, 22 Feb 2016, H.J. Lu wrote:
> > Typo? What is the meaning of "dynamic relocation available at
> > runtime". Are you talking about a relocation entry or the relocation
> > process?
>
> Dynamic relocation isn't available with static linking.
So you _are_ talking about the process. I think it's customary to call
such executables "dynamic", or perhaps non-static, isn't it? (Why I'm
confused with your wording: a dynamic executable which happens to have no
dynamic reloc entries, has "no dynamic relocation available at runtime",
and so we couldn't add one :))
> > How about "When creating a dynamic executable the link editor should
> > ..."?
So, I still can understand my version better (possibly with
s/dynamic/non-static/) :)
> >> the link editor should generate dynamic relocations against
> >> unresolved weak symbols so that their values will be resolved at
> >> run-time.
Ciao,
Michael.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Alan Modra
0 siblings, 2 replies; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: Michael Matz; +Cc: gnu-gabi
On Mon, Feb 22, 2016 at 10:28 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Feb 22, 2016 at 10:17 AM, Michael Matz <matz@suse.de> wrote:
>> Hi,
>>
>> On Mon, 22 Feb 2016, H.J. Lu wrote:
>>
>>> > Typo? What is the meaning of "dynamic relocation available at
>>> > runtime". Are you talking about a relocation entry or the relocation
>>> > process?
>>>
>>> Dynamic relocation isn't available with static linking.
>>
>> So you _are_ talking about the process. I think it's customary to call
>> such executables "dynamic", or perhaps non-static, isn't it? (Why I'm
>> confused with your wording: a dynamic executable which happens to have no
>> dynamic reloc entries, has "no dynamic relocation available at runtime",
>> and so we couldn't add one :))
>>
>>> > How about "When creating a dynamic executable the link editor should
>>> > ..."?
>>
>> So, I still can understand my version better (possibly with
>> s/dynamic/non-static/) :)
>>
>
> Let's go with:
>
> When creating dynamic executable, the link editor should generate dynamic
> relocations against unresolved weak symbols so that their values will be
> resolved at run-time.
>
Second thought. To generate dynamic relocation for R_X86_64_32
against fun in:
[hjl@gnu-6 pr19704]$ objdump -dwr foo.o
foo.o: file format elf64-x86-64
Disassembly of section .text.startup:
0000000000000000 <main>:
0: b8 00 00 00 00 mov $0x0,%eax 1: R_X86_64_32 fun
5: 48 85 c0 test %rax,%rax
8: 74 10 je 1a <main+0x1a>
a: 48 83 ec 08 sub $0x8,%rsp
e: e8 00 00 00 00 callq 13 <main+0x13> f: R_X86_64_PC32 fun-0x4
13: 31 c0 xor %eax,%eax
15: 48 83 c4 08 add $0x8,%rsp
19: c3 retq
1a: 31 c0 xor %eax,%eax
1c: c3 retq
[hjl@gnu-6 pr19704]$
we create executable with dynamic R_X86_64_32 relocation against
fun .text section, which leads to DT_TEXTREL. Is this what we want?
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` Alan Modra
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
1 sibling, 1 reply; 34+ messages in thread
From: Alan Modra @ 2016-01-01 0:00 UTC (permalink / raw)
To: H.J. Lu; +Cc: Michael Matz, gnu-gabi
On Tue, Feb 23, 2016 at 09:10:51AM -0800, H.J. Lu wrote:
> At run-time, there is no difference between weak defined and non-weak
> defined symbols.
This is not true, and even if it was..
> If we change defined weak symbol behavior, we also
> need to change defined non-weak symbol behavior.
..it does not follow that run-time loader treatment of weak vs. strong
symbols should determine linker behaviour regarding the same.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` Michael Matz
@ 2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
0 siblings, 1 reply; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: Michael Matz; +Cc: Carlos O'Donell, Alan Modra, gnu-gabi
On Wed, Feb 24, 2016 at 9:08 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Wed, 24 Feb 2016, H.J. Lu wrote:
>
>> >> I was saying as far as ld was concerned, weak defined and non-weak
>> >> defined dynamic symbols would be treated equally at run-time. Do you
>> >> agree with me?
>> >
>> > I at least don't. The difference is that a defined weak symbol (at
>> > link edit time) might become undefined at runtime. A defined non-weak
>> > symbol can't. So they have to be handled differently.
>> >
>>
>> How?
>
> Like right now (mostly)? Resolution of weak symbols needs to be deferred
> to the dynamic linker, in particular they mustn't be resolved (to either
> zero or an address) at link edit time. There's one case where weak
> symbols can be resolved early: if at link edit time the executable itself
> provides a definition of 'foo' then weak references can be directly
> resolved to that one (because at runtime of that exectuable there's no
> possibility to not have this symbol defined).
>
> To not do that (i.e. resolve them always at link edit time) breaks various
> current uses of weak symbols. We could do that of course, but I don't
> think that would be useful to users.
I suggest you raise this issue at
https://groups.google.com/forum/#!forum/generic-abi
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` Alan Modra
@ 2016-01-01 0:00 ` Carlos O'Donell
2016-01-01 0:00 ` H.J. Lu
0 siblings, 1 reply; 34+ messages in thread
From: Carlos O'Donell @ 2016-01-01 0:00 UTC (permalink / raw)
To: Alan Modra, H.J. Lu; +Cc: Michael Matz, gnu-gabi
On 02/23/2016 08:56 PM, Alan Modra wrote:
> On Tue, Feb 23, 2016 at 05:18:16PM -0800, H.J. Lu wrote:
>> On Tue, Feb 23, 2016 at 5:04 PM, Alan Modra <amodra@gmail.com> wrote:
>>> On Tue, Feb 23, 2016 at 09:10:51AM -0800, H.J. Lu wrote:
>>>> At run-time, there is no difference between weak defined and non-weak
>>>> defined symbols.
>>>
>>> This is not true, and even if it was..
>>>
>>
>> Please do
>>
>> # git grep dl_dynamic_weak
>>
>> in glibc to see it for yourself.
>
> That's exactly the code that shows ld.so can treat weak and strong
> symbols differently! (And yes, I know the default setting of
> dl_dynamic_weak.)
>
> Besides, the main point of my comment was that it is simply faulty
> reasoning to claim that the linker needs to change because of some
> ld.so behaviour.
Agreed. Anything that brings back weak symbols into the dynamic loader
is going to be highly suspect to me, and require a lot of explaining.
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
0 siblings, 1 reply; 34+ messages in thread
From: Michael Matz @ 2016-01-01 0:00 UTC (permalink / raw)
To: H.J. Lu; +Cc: Carlos O'Donell, Alan Modra, gnu-gabi
Hi,
On Wed, 24 Feb 2016, H.J. Lu wrote:
> >> I was saying as far as ld was concerned, weak defined and non-weak
> >> defined dynamic symbols would be treated equally at run-time. Do you
> >> agree with me?
> >
> > I at least don't. The difference is that a defined weak symbol (at
> > link edit time) might become undefined at runtime. A defined non-weak
> > symbol can't. So they have to be handled differently.
> >
>
> How?
Like right now (mostly)? Resolution of weak symbols needs to be deferred
to the dynamic linker, in particular they mustn't be resolved (to either
zero or an address) at link edit time. There's one case where weak
symbols can be resolved early: if at link edit time the executable itself
provides a definition of 'foo' then weak references can be directly
resolved to that one (because at runtime of that exectuable there's no
possibility to not have this symbol defined).
To not do that (i.e. resolve them always at link edit time) breaks various
current uses of weak symbols. We could do that of course, but I don't
think that would be useful to users.
Ciao,
Michael.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` Michael Matz
@ 2016-01-01 0:00 ` H.J. Lu
0 siblings, 0 replies; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: Michael Matz; +Cc: Carlos O'Donell, Alan Modra, gnu-gabi
On Wed, Feb 24, 2016 at 9:54 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Wed, 24 Feb 2016, H.J. Lu wrote:
>
>> > To not do that (i.e. resolve them always at link edit time) breaks
>> > various current uses of weak symbols. We could do that of course, but
>> > I don't think that would be useful to users.
>>
>> I suggest you raise this issue at
>>
>> https://groups.google.com/forum/#!forum/generic-abi
>
> You want to change existing behaviour, not me. The Solaris and HP-UX guys
> already stated what they do, and are unlikely to want to change behaviour.
> I don't think we can change the gABI to be more explicit about weak
> symbols (not the least because Solaris and HP-UX already differ in the
> details), so I think we're left with discussing it here.
>
There is a difference between yours and mine. I wanted to
clarify reference to undefined weak symbols in executable.
You want to change reference to defined weak symbols in
executable. It is undefined weak vs defined weak.
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` Michael Matz
@ 2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
0 siblings, 1 reply; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: Michael Matz; +Cc: Alan Modra, gnu-gabi
On Tue, Feb 23, 2016 at 5:55 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 23 Feb 2016, H.J. Lu wrote:
>
>> On Mon, Feb 22, 2016 at 8:40 PM, Alan Modra <amodra@gmail.com> wrote:
>> >
>> > However, that might be a bad idea. Lots of C++ code uses weak symbols
>> > for functions defined in header files, and other objects with vague
>> > linkage. These result in weak definitions in eg. libstdc++.so. I'm
>> > not sure how many executables take the address of such functions and
>> > thus might become DT_TEXTREL.
>>
>> Most, if not all, of programs will have DT_TEXTREL on x86 if undefined
>> weak symbols require dynamic relocations.
>
> Hmm, that's less than ideal of course. Well, if the goal is to make PIC
> and non-PIC the same, we could also go the opposite way: make PIC behave
> like non-PIC, i.e. resolve weak symbols always at link editing time. That
> of course would remove features (can't change libs at runtime anymore, if
> they change in definedness of such a symbol).
This "feature" never worked on x86 for non-PIC input.
> Or, a third variant: change the compiler to emit PIC like code for taking
> addresses of weak symbols also in generally non-PIC code, so we could
> avoid TEXTREL.
>
> I think the ideal solution would be that last one, change link editor now
> to behave like with PIC code, and eventually fix the compiler to not have
> to generate TEXTREL.
If we change ld now, all of a sudden, x86 binaris are marked with
DT_TEXTREL. What we can do is to add a new linker command
option, -z dynamic-undef-weak, and GCC passes it to ld only when
compiler is changed to generate PIC-like code for address of all
undefined symbol in text section.
> Note that the existence of DT_TEXTREL itself isn't that bad: only those
> pages that actually contain relocations will be unshared, so for the
> example of crtbegin.o it's only one page per process. In addition
> crtbegin could of course always be PIC code, avoiding the issue.
>
> I've looked at a normal c++ program (zypper) and the only weak undef
> symbols are those from crtbegin. There are many other weak symbols, but
> they are defined in the executable itself (it's mostly template
> instantiations), so pose no problem.
>
>
I checked cc1plus and found:
[hjl@gnu-6 5.3.1]$ readelf -sW cc1plus| grep WEAK | grep UND
33: 0000000000000000 0 FUNC WEAK DEFAULT UND
pthread_cond_signal@GLIBC_2.3.2 (3)
2924: 0000000000000000 0 FUNC WEAK DEFAULT UND
pthread_cond_broadcast@GLIBC_2.3.2 (3)
4861: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_key_create
6330: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_getspecific
7205: 0000000000000000 0 FUNC WEAK DEFAULT UND
pthread_mutex_unlock@GLIBC_2.2.5 (2)
7719: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_key_delete
9118: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __pthread_key_create
11985: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
12269: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_once
15201: 0000000000000000 0 FUNC WEAK DEFAULT UND
pthread_mutex_lock@GLIBC_2.2.5 (2)
15794: 0000000000000000 0 FUNC WEAK DEFAULT UND
pthread_cond_wait@GLIBC_2.3.2 (3)
18312: 0000000000000000 0 NOTYPE WEAK DEFAULT UND
_ITM_deregisterTMCloneTable
19108: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_setspecific
19649: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
19871: 0000000000000000 0 NOTYPE WEAK DEFAULT UND
_ITM_registerTMCloneTable
20107: 0000000000000000 0 FUNC WEAK DEFAULT UND
pthread_cond_destroy@GLIBC_2.3.2 (3)
18570: 0000000000000000 0 FUNC WEAK DEFAULT UND
pthread_cond_signal@@GLIBC_2.3.2
21461: 0000000000000000 0 FUNC WEAK DEFAULT UND
pthread_cond_broadcast@@GLIBC_2.3.2
23398: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_key_create
24867: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_getspecific
25742: 0000000000000000 0 FUNC WEAK DEFAULT UND
pthread_mutex_unlock@@GLIBC_2.2.5
26256: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_key_delete
27655: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __pthread_key_create
30521: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
30805: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_once
33737: 0000000000000000 0 FUNC WEAK DEFAULT UND
pthread_mutex_lock@@GLIBC_2.2.5
34330: 0000000000000000 0 FUNC WEAK DEFAULT UND
pthread_cond_wait@@GLIBC_2.3.2
36848: 0000000000000000 0 NOTYPE WEAK DEFAULT UND
_ITM_deregisterTMCloneTable
37644: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_setspecific
38185: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
38407: 0000000000000000 0 NOTYPE WEAK DEFAULT UND
_ITM_registerTMCloneTable
38643: 0000000000000000 0 FUNC WEAK DEFAULT UND
pthread_cond_destroy@@GLIBC_2.3.2
[hjl@gnu-6 5.3.1]$
Do you know how many of them lead to DT_TEXTREL?
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` Carlos O'Donell
@ 2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
0 siblings, 1 reply; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: Alan Modra, Michael Matz, gnu-gabi
On Tue, Feb 23, 2016 at 6:04 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 02/23/2016 08:56 PM, Alan Modra wrote:
>> On Tue, Feb 23, 2016 at 05:18:16PM -0800, H.J. Lu wrote:
>>> On Tue, Feb 23, 2016 at 5:04 PM, Alan Modra <amodra@gmail.com> wrote:
>>>> On Tue, Feb 23, 2016 at 09:10:51AM -0800, H.J. Lu wrote:
>>>>> At run-time, there is no difference between weak defined and non-weak
>>>>> defined symbols.
>>>>
>>>> This is not true, and even if it was..
>>>>
>>>
>>> Please do
>>>
>>> # git grep dl_dynamic_weak
>>>
>>> in glibc to see it for yourself.
>>
>> That's exactly the code that shows ld.so can treat weak and strong
>> symbols differently! (And yes, I know the default setting of
>> dl_dynamic_weak.)
>>
>> Besides, the main point of my comment was that it is simply faulty
>> reasoning to claim that the linker needs to change because of some
>> ld.so behaviour.
>
> Agreed. Anything that brings back weak symbols into the dynamic loader
> is going to be highly suspect to me, and require a lot of explaining.
>
I was saying as far as ld was concerned, weak defined and non-weak
defined dynamic symbols would be treated equally at run-time. Do you
agree with me?
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Specify how undefined weak symbol should be resolved in executable
@ 2016-01-01 0:00 H.J. Lu
2016-01-01 0:00 ` H.J. Lu
0 siblings, 1 reply; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: gnu-gabi
Currently when building executable, undefined weak symbol is resolved
differently, depending on if the relocatable input is compiled with PIC or
not:
hjl@gnu-tools-1 weak-1]$ cat x.c
extern void __attribute__ ((weak)) fun (void);
int main (void)
{
if (&fun != 0)
fun ();
return 0;
}
[hjl@gnu-tools-1 weak-1]$ make
gcc -B./ -O2 -o x x.c
gcc -B./ -O2 -o y x.c -fPIC
readelf -r x
Relocation section '.rela.dyn' at offset 0x328 contains 1 entries:
Offset Info Type Sym. Value Sym. Name + Addend
000000600870 000200000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0
Relocation section '.rela.plt' at offset 0x340 contains 1 entries:
Offset Info Type Sym. Value Sym. Name + Addend
000000600890 000100000007 R_X86_64_JUMP_SLO 0000000000000000
__libc_start_main@GLIBC_2.2.5 + 0
There is no dynamic relocation against fun, whose value is
resolved to zero at link-time.
readelf -r y
Relocation section '.rela.dyn' at offset 0x348 contains 2 entries:
Offset Info Type Sym. Value Sym. Name + Addend
0000006008a0 000100000006 R_X86_64_GLOB_DAT 0000000000000000 fun + 0
0000006008a8 000300000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0
Relocation section '.rela.plt' at offset 0x378 contains 1 entries:
Offset Info Type Sym. Value Sym. Name + Addend
0000006008c8 000200000007 R_X86_64_JUMP_SLO 0000000000000000
__libc_start_main@GLIBC_2.2.5 + 0
[hjl@gnu-tools-1 weak-1]$
There is dynamic relocation against fun, whose value is resolved
at runt-time. We should make it consistent, regardless if input
relocatable file is compiled with PIC or not.
I raised the issue at gABI:
https://groups.google.com/d/msg/generic-abi/Ckq19PfLxyk/eCbXPofkAQAJ
But if gABI change is incompatible with other OSes, we need to
specify it in GNU ABI.
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` H.J. Lu
@ 2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` Szabolcs Nagy
0 siblings, 1 reply; 34+ messages in thread
From: Michael Matz @ 2016-01-01 0:00 UTC (permalink / raw)
To: H.J. Lu; +Cc: Alan Modra, gnu-gabi
Hi,
On Tue, 23 Feb 2016, H.J. Lu wrote:
> > Hmm, that's less than ideal of course. Well, if the goal is to make
> > PIC and non-PIC the same, we could also go the opposite way: make PIC
> > behave like non-PIC, i.e. resolve weak symbols always at link editing
> > time. That of course would remove features (can't change libs at
> > runtime anymore, if they change in definedness of such a symbol).
>
> This "feature" never worked on x86 for non-PIC input.
True (and that's exactly the difference between PIC and non-PIC).
> If we change ld now, all of a sudden, x86 binaris are marked with
> DT_TEXTREL. What we can do is to add a new linker command option, -z
> dynamic-undef-weak, and GCC passes it to ld only when compiler is
> changed to generate PIC-like code for address of all undefined symbol in
> text section.
Hmmnyeah, possible.
> > Note that the existence of DT_TEXTREL itself isn't that bad: only those
> > pages that actually contain relocations will be unshared, so for the
> > example of crtbegin.o it's only one page per process. In addition
> > crtbegin could of course always be PIC code, avoiding the issue.
> >
> > I've looked at a normal c++ program (zypper) and the only weak undef
> > symbols are those from crtbegin. There are many other weak symbols, but
> > they are defined in the executable itself (it's mostly template
> > instantiations), so pose no problem.
> >
> >
>
> I checked cc1plus and found:
>
> [hjl@gnu-6 5.3.1]$ readelf -sW cc1plus| grep WEAK | grep UND
Careful, that includes .symtab, not only .dynsym. These are the .dynsyms:
> 33: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_signal@GLIBC_2.3.2 (3)
> 2924: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_broadcast@GLIBC_2.3.2 (3)
> 4861: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_key_create
> 6330: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_getspecific
> 7205: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_mutex_unlock@GLIBC_2.2.5 (2)
> 7719: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_key_delete
> 9118: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __pthread_key_create
> 11985: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
> 12269: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_once
> 15201: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_mutex_lock@GLIBC_2.2.5 (2)
> 15794: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_wait@GLIBC_2.3.2 (3)
> 18312: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterTMCloneTable
> 19108: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_setspecific
> 19649: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
> 19871: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_registerTMCloneTable
> 20107: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_destroy@GLIBC_2.3.2 (3)
After here it's .symtab:
> 18570: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_signal@@GLIBC_2.3.2
>
> Do you know how many of them lead to DT_TEXTREL?
I think all those not going via the PLT, hence looking at the relocs for
those symbols involved, ignoring JUMP_SLOT relocs will give you that. For
my cc1plus it's only this:
pthread_cancel
(of those that are undef-weak), and only one reference.
Ciao,
Michael.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Specify how undefined weak symbol should be resolved in executable
2016-01-01 0:00 ` Alan Modra
@ 2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Alan Modra
0 siblings, 1 reply; 34+ messages in thread
From: H.J. Lu @ 2016-01-01 0:00 UTC (permalink / raw)
To: Alan Modra; +Cc: Michael Matz, gnu-gabi
On Tue, Feb 23, 2016 at 5:04 PM, Alan Modra <amodra@gmail.com> wrote:
> On Tue, Feb 23, 2016 at 09:10:51AM -0800, H.J. Lu wrote:
>> At run-time, there is no difference between weak defined and non-weak
>> defined symbols.
>
> This is not true, and even if it was..
>
Please do
# git grep dl_dynamic_weak
in glibc to see it for yourself.
--
H.J.
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2016-02-24 18:09 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-01 0:00 Specify how undefined weak symbol should be resolved in executable H.J. Lu
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Alan Modra
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` Szabolcs Nagy
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Alan Modra
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Alan Modra
2016-01-01 0:00 ` Carlos O'Donell
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).