gold linker 2.22 regressed for DragonFly

gold linker 2.22 regressed for DragonFly

[John Marino]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

When binutils 2.21 was imported into DragonFly, gold could successful 
link world and kernel, but not the kernel modules.  When binutils 2.22 
was imported, gold can no longer even link itself.

After executing "gmake check-TESTS", the new version of gold linked by 
gold segfaults immediately.  The General_Options->format() method 
returns null, crashing string_to_object_format in options.cc.  I'm not 
very strong in C++, so I'm having trouble figuring out why format() is 
not getting defined, or what has changed between gold 2.21 and gold 2.22.

The backtrace is attached.  I'm sure somebody here should be able to 
point me to code that should be modified to support DragonFly BSD.

Thanks,
John

[-- Attachment #2: gdb.txt --]
[-- Type: text/plain, Size: 1165 bytes --]

The program being debugged has been started already.
Start it from the beginning? (y or n) 
Starting program: /home/marino/workzone/test-222/gold/ld1 

Program received signal SIGSEGV, Segmentation fault.
0x000000000052e534 in gold::General_options::string_to_object_format (arg=0x0)
    at ../../binutils-2.22/gold/options.cc:655
655	  if (strncmp(arg, "elf", 3) == 0)
#0  0x000000000052e534 in gold::General_options::string_to_object_format (
    arg=0x0) at ../../binutils-2.22/gold/options.cc:655
#1  0x000000000053b5e2 in format_enum (this=0x62a5fe)
    at ../../binutils-2.22/gold/options.cc:937
#2  copy_from_options (options=<optimized out>, this=<optimized out>)
    at ../../binutils-2.22/gold/options.h:1545
#3  Position_dependent_options (options=<optimized out>, this=<optimized out>)
    at ../../binutils-2.22/gold/options.h:1539
#4  gold::Command_line::Command_line (this=0x7fffffff98e0)
    at ../../binutils-2.22/gold/options.cc:1341
#5  0x00000000004042a9 in main (argc=1, argv=0x7ffffffff5c8)
    at ../../binutils-2.22/gold/main.cc:163
$2 = 0x0
A debugging session is active.

	Inferior 1 [process 58273] will be killed.

Quit anyway? (y or n) 

Re: gold linker 2.22 regressed for DragonFly

[Ian Lance Taylor]

John Marino <binutils@marino.st> writes:

> When binutils 2.21 was imported into DragonFly, gold could successful
> link world and kernel, but not the kernel modules.  When binutils 2.22
> was imported, gold can no longer even link itself.
>
> After executing "gmake check-TESTS", the new version of gold linked by
> gold segfaults immediately.  The General_Options->format() method
> returns null, crashing string_to_object_format in options.cc.  I'm not
> very strong in C++, so I'm having trouble figuring out why format() is
> not getting defined, or what has changed between gold 2.21 and gold
> 2.22.
>
> The backtrace is attached.  I'm sure somebody here should be able to
> point me to code that should be modified to support DragonFly BSD.
>
> Thanks,
> John
>
> The program being debugged has been started already.
> Start it from the beginning? (y or n) 
> Starting program: /home/marino/workzone/test-222/gold/ld1 
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000000052e534 in gold::General_options::string_to_object_format (arg=0x0)
>     at ../../binutils-2.22/gold/options.cc:655
> 655	  if (strncmp(arg, "elf", 3) == 0)
> #0  0x000000000052e534 in gold::General_options::string_to_object_format (
>     arg=0x0) at ../../binutils-2.22/gold/options.cc:655

string_to_object_format is being called with a NULL pointer.

> #1  0x000000000053b5e2 in format_enum (this=0x62a5fe)
>     at ../../binutils-2.22/gold/options.cc:937

This line is
  return General_options::string_to_object_format(this->format());
so this->format() is return a NULL string.

That should not happen.  this->format() is going to return the value of
this->format_.value.  That should be initialized to "elf" and nothing
should ever change it to NULL.  In this case "this" appears to refer to
the static variable Position_dependent_options::default_options_.

I'm not aware of anything that has changed in this area between binutils
2.21 and 2.22.  The same code is in 2.21.

I guess I would debug it by verifying that
Position_independent_options::default_options_.format_.value is in fact
initialized to "elf".  If not, why not?  If it is, when does it change?

Ian

Re: gold linker 2.22 regressed for DragonFly

[John Marino]

On 12/2/2011 5:58 AM, Ian Lance Taylor wrote:
> John Marino<binutils@marino.st>  writes:
>
> string_to_object_format is being called with a NULL pointer.
>
>> #1  0x000000000053b5e2 in format_enum (this=0x62a5fe)
>>      at ../../binutils-2.22/gold/options.cc:937
> This line is
>    return General_options::string_to_object_format(this->format());
> so this->format() is return a NULL string.
>
> That should not happen.  this->format() is going to return the value of
> this->format_.value.  That should be initialized to "elf" and nothing
> should ever change it to NULL.  In this case "this" appears to refer to
> the static variable Position_dependent_options::default_options_.
>
> I'm not aware of anything that has changed in this area between binutils
> 2.21 and 2.22.  The same code is in 2.21.
>
> I guess I would debug it by verifying that
> Position_independent_options::default_options_.format_.value is in fact
> initialized to "elf".  If not, why not?  If it is, when does it change?
>
> Ian

I need to stress that gold built with ld does not have this problem.  
It's only gold built with gold that segfaults.  Does that affect your 
answer?  By the way, the format initialization is all happening via 
macro, so I had to "gcc -E" to even see what it's doing.  The code looks 
fine to me.

I'll try to analysis gold-by-gold with gdb later to see if I can get to 
the elf initiation or if it just skips it altogether.  I suspect that 
it's never initialized.

John

Re: gold linker 2.22 regressed for DragonFly

[Ian Lance Taylor]

John Marino <binutils@marino.st> writes:

> I need to stress that gold built with ld does not have this problem.
> It's only gold built with gold that segfaults.  Does that affect your
> answer?

Try using the gold option --no-ctors-in-init-array.

Ian

Re: gold linker 2.22 regressed for DragonFly

[John Marino]

On 12/2/2011 3:27 PM, Ian Lance Taylor wrote:
> John Marino <binutils@marino.st> writes:
> 
>> I need to stress that gold built with ld does not have this problem.
>> It's only gold built with gold that segfaults.  Does that affect your
>> answer?
> 
> Try using the gold option --no-ctors-in-init-array.
> 
> Ian

I'm sorry that I had to put this away for a while, but I've picked it
back up today.

Gold build with ld will function without segfaults and produces executables.
Gold build with gold segfaults.  It ignores all command-line options.

I modified the makefile to set optimization level to 0.  That let me see
the values of variables in gdb.  Using gdb on ld-new (gold built with
ld), "print options" on gdb shows a properly defined option set of
General_options class.  Doing the same for ld1 (gold built by gold)
shows every single option with null pointers.  Not even strings like
"Report usage information" and "Report version information" are included.

So the problem lies in options.h within the General_options class.  I
have no idea what ld-new is doing wrong such that ld1 can't built its
option set.  These definitions are built with macros though.

John

Re: gold linker 2.22 regressed for DragonFly

[Ian Lance Taylor]

John Marino <binutils@marino.st> writes:

> On 12/2/2011 3:27 PM, Ian Lance Taylor wrote:
>> John Marino <binutils@marino.st> writes:
>> 
>>> I need to stress that gold built with ld does not have this problem.
>>> It's only gold built with gold that segfaults.  Does that affect your
>>> answer?
>> 
>> Try using the gold option --no-ctors-in-init-array.
>> 
>> Ian
>
> I'm sorry that I had to put this away for a while, but I've picked it
> back up today.
>
> Gold build with ld will function without segfaults and produces executables.
> Gold build with gold segfaults.  It ignores all command-line options.
>
> I modified the makefile to set optimization level to 0.  That let me see
> the values of variables in gdb.  Using gdb on ld-new (gold built with
> ld), "print options" on gdb shows a properly defined option set of
> General_options class.  Doing the same for ld1 (gold built by gold)
> shows every single option with null pointers.  Not even strings like
> "Report usage information" and "Report version information" are included.
>
> So the problem lies in options.h within the General_options class.  I
> have no idea what ld-new is doing wrong such that ld1 can't built its
> option set.  These definitions are built with macros though.


Did you try using the --no-ctors-in-init-array option?

Ian

Re: gold linker 2.22 regressed for DragonFly

[John Marino]

On 1/2/2012 3:05 AM, Ian Lance Taylor wrote:
> John Marino <binutils@marino.st> writes:
> 
>> On 12/2/2011 3:27 PM, Ian Lance Taylor wrote:
>>> John Marino <binutils@marino.st> writes:
>>>
>>>> I need to stress that gold built with ld does not have this problem.
>>>> It's only gold built with gold that segfaults.  Does that affect your
>>>> answer?
>>>
>>> Try using the gold option --no-ctors-in-init-array.
>>>
>>> Ian
>>
>> I'm sorry that I had to put this away for a while, but I've picked it
>> back up today.
>>
>> Gold build with ld will function without segfaults and produces executables.
>> Gold build with gold segfaults.  It ignores all command-line options.
>>
>> I modified the makefile to set optimization level to 0.  That let me see
>> the values of variables in gdb.  Using gdb on ld-new (gold built with
>> ld), "print options" on gdb shows a properly defined option set of
>> General_options class.  Doing the same for ld1 (gold built by gold)
>> shows every single option with null pointers.  Not even strings like
>> "Report usage information" and "Report version information" are included.
>>
>> So the problem lies in options.h within the General_options class.  I
>> have no idea what ld-new is doing wrong such that ld1 can't built its
>> option set.  These definitions are built with macros though.
> 
> 
> Did you try using the --no-ctors-in-init-array option?
> 
> Ian

Yes, I modified the gold makefile to add that to ld1_LDFLAGS and it
makes no difference.  The resultant ld1 will still segfault as it tries
to build ld2.

John

Re: gold linker 2.22 regressed for DragonFly

[Ian Lance Taylor]

John Marino <binutils@marino.st> writes:

> On 1/2/2012 3:05 AM, Ian Lance Taylor wrote:
>> John Marino <binutils@marino.st> writes:
>> 
>>> On 12/2/2011 3:27 PM, Ian Lance Taylor wrote:
>>>> John Marino <binutils@marino.st> writes:
>>>>
>>>>> I need to stress that gold built with ld does not have this problem.
>>>>> It's only gold built with gold that segfaults.  Does that affect your
>>>>> answer?
>>>>
>>>> Try using the gold option --no-ctors-in-init-array.
>>>>
>>>> Ian
>>>
>>> I'm sorry that I had to put this away for a while, but I've picked it
>>> back up today.
>>>
>>> Gold build with ld will function without segfaults and produces executables.
>>> Gold build with gold segfaults.  It ignores all command-line options.
>>>
>>> I modified the makefile to set optimization level to 0.  That let me see
>>> the values of variables in gdb.  Using gdb on ld-new (gold built with
>>> ld), "print options" on gdb shows a properly defined option set of
>>> General_options class.  Doing the same for ld1 (gold built by gold)
>>> shows every single option with null pointers.  Not even strings like
>>> "Report usage information" and "Report version information" are included.
>>>
>>> So the problem lies in options.h within the General_options class.  I
>>> have no idea what ld-new is doing wrong such that ld1 can't built its
>>> option set.  These definitions are built with macros though.
>> 
>> 
>> Did you try using the --no-ctors-in-init-array option?
>> 
>> Ian
>
> Yes, I modified the gold makefile to add that to ld1_LDFLAGS and it
> makes no difference.  The resultant ld1 will still segfault as it tries
> to build ld2.

What linker are you using to build ld1?

You said earlier that gold built with ld does not have a problem.  Only
gold build with gold segfaults.  I am suggesting that you use
--no-ctors-in-init-array when running gold.  In fact you should try just
editing options.h to make --no-ctors-in-init-array the default to see if
that fixes all your problems.

Otherwise, the problem you describe suggests that global constructors
are not running correctly when running gold itself, but I don't know why
that would happen if you are not linking gold itself with gold.

Ian

Re: gold linker 2.22 regressed for DragonFly

[John Marino]

On 1/2/2012 7:38 PM, Ian Lance Taylor wrote:
> 
> What linker are you using to build ld1?
> 

I'm just running a makefile target ">gmake check-TESTS".
The makefile makes a copy of ld-new (which is gold) and names the copy
ld, so gold is used to build ld1.

> You said earlier that gold built with ld does not have a problem.  

To be clear, I'm trying to convey that the first gold built by the old
ld linker doesn't segfault when executed.  I don't know how well it
works outside of that.


> Only gold built with gold segfaults.  I am suggesting that you use
> --no-ctors-in-init-array when running gold.  In fact you should try just
> editing options.h to make --no-ctors-in-init-array the default to see if
> that fixes all your problems.

Editing ld1_LDFLAGS to add --no-ctors-in-init-array is effectively this.
Also the title of this post is "gold linker 2.22 REGRESSED for
DragonFly".  gold linker 2.21 doesn't need this switch to build itself.

I edited options.h to set ctors-in-init-array to false, followed by
">gmake clean" and ">gmake check-TESTS".

The result is better:
==================
All 2 tests passed
==================

Then I tried ">gmake check"
It got pretty far in the testsuite, complete through "split_i386.sh" and
starting failing at incremental-dump.cc due to numerous missing headers.
 I'm got a separate build directory, so the test might not be accounting
for that (e.g. source is in {top}/binutils-2.22 and my build directory
is {top}/build-b222).

Is that options.h generated or is ctors-in-init-array hardcoded to true?

Thanks for your help,
John

Re: gold linker 2.22 regressed for DragonFly

[John Marino]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

On 1/2/2012 8:26 PM, John Marino wrote:
> 
> Then I tried ">gmake check"
> It got pretty far in the testsuite, complete through "split_i386.sh" and
> starting failing at incremental-dump.cc due to numerous missing headers.
>  I'm got a separate build directory, so the test might not be accounting
> for that (e.g. source is in {top}/binutils-2.22 and my build directory
> is {top}/build-b222).

I just drilled into the testsuite directory and typed ">gmake
check-TESTS" and went through 137 tests.  DragonFly failed 42 of them
(attached).

John.



[-- Attachment #2: test-suite.log --]
[-- Type: text/plain, Size: 10159 bytes --]

========================================
   gold 0.1: testsuite/test-suite.log   
========================================

42 of 137 tests failed.  

.. contents:: :depth: 2


FAIL: incremental_test.sh (exit: 1)
===================================

cat: incremental_test.stdout: No such file or directory
../../../binutils-2.22/gold/testsuite/incremental_test.sh: cannot open incremental_test.stdout: No such file or directory
grep: incremental_test.dump: No such file or directory
Did not find expected output in incremental_test.dump:
   Input sections: .* incremental_test_1.o  *1 

Actual output below:
cat: incremental_test.dump: No such file or directory

FAIL: gc_orphan_section_test.sh (exit: 1)
=========================================

grep: gc_orphan_section_test.stdout: No such file or directory
grep: gc_orphan_section_test.stdout: No such file or directory
Garbage collection should not discard foo

FAIL: icf_test.sh (exit: 1)
===========================

grep: icf_test.stdout: No such file or directory
grep: icf_test.stdout: No such file or directory
Identical Code Folding failed to fold folded_func and kept_func

FAIL: icf_keep_unique_test.sh (exit: 1)
=======================================

grep: icf_keep_unique_test.stdout: No such file or directory
grep: icf_keep_unique_test.stdout: No such file or directory
Identical Code Folding with keep-unique failed to unfold kept_func

FAIL: icf_safe_test.sh (exit: 1)
================================

grep: icf_safe_test_2.stdout: No such file or directory
grep: icf_safe_test_1.stdout: No such file or directory
grep: icf_safe_test_1.stdout: No such file or directory
Safe Identical Code Folding folded kept_func_1 and kept_func_2

FAIL: icf_safe_so_test.sh (exit: 1)
===================================

Symbol foo_prot not present, possibly folded.

FAIL: final_layout.sh (exit: 2)
===============================

awk: can't open file final_layout.stdout
 source line number 2

FAIL: icf_preemptible_functions_test.sh (exit: 1)
=================================================

grep: icf_preemptible_functions_test.stdout: No such file or directory
grep: icf_preemptible_functions_test.stdout: No such file or directory
Identical Code Folding should not fold _Z3foov and _Z3barv

FAIL: icf_string_merge_test.sh (exit: 1)
========================================

grep: icf_string_merge_test.stdout: No such file or directory
grep: icf_string_merge_test.stdout: No such file or directory
Identical Code Folding should not fold get1 and get2

FAIL: icf_sht_rel_addend_test.sh (exit: 1)
==========================================

grep: icf_sht_rel_addend_test.stdout: No such file or directory
grep: icf_sht_rel_addend_test.stdout: No such file or directory
Identical Code Folding should not fold name1 and name2

FAIL: weak_plt.sh (exit: 1)
===========================

/usr/libexec/ld-elf.so.2: Cannot open "./weak_plt_shared.so"

FAIL: debug_msg.sh (exit: 1)
============================

grep: debug_msg.err: No such file or directory
Did not find expected error in debug_msg.err:
   debug_msg.o:debug_msg.cc:function fn_array: error: undefined reference to 'undef_fn1()'

Actual error output below:
cat: debug_msg.err: No such file or directory

FAIL: undef_symbol.sh (exit: 1)
===============================

grep: undef_symbol.err: No such file or directory
Did not find expected error:
   undef_symbol.so: error: undefined reference to 'a'

Actual error output below:
cat: undef_symbol.err: No such file or directory

FAIL: ver_test_2.sh (exit: 1)
=============================

grep: ver_test_2.syms: No such file or directory
Did not find expected symbol in ver_test_2.syms:
   t1_2@VER2

Actual output below:
cat: ver_test_2.syms: No such file or directory

FAIL: ver_test_4.sh (exit: 1)
=============================

grep: ver_test_4.syms: No such file or directory
Did not find expected symbol in ver_test_4.syms:
   t1_2@@VER2

Actual output below:
cat: ver_test_4.syms: No such file or directory

FAIL: ver_test_5.sh (exit: 1)
=============================

grep: ver_test_5.syms: No such file or directory
Did not find expected symbol in ver_test_5.syms:
   t3_2@@VER5

Actual output below:
cat: ver_test_5.syms: No such file or directory

FAIL: ver_test_7.sh (exit: 1)
=============================

grep: ver_test_7.syms: No such file or directory
Did not find expected symbol in ver_test_7.syms:
   t2_2@@VER2

Actual output below:
cat: ver_test_7.syms: No such file or directory

FAIL: ver_test_10.sh (exit: 1)
==============================

grep: ver_test_10.syms: No such file or directory
Did not find expected symbol in ver_test_10.syms:
   GLOBAL.*t3_2

Actual output below:
cat: ver_test_10.syms: No such file or directory

FAIL: relro_test.sh (exit: 1)
=============================

grep: relro_test.stdout: No such file or directory
grep: relro_test.stdout: No such file or directory
Did not find a PT_GNU_RELRO segment.

FAIL: ver_matching_test.sh (exit: 1)
====================================

grep: ver_matching_test.stdout: No such file or directory
Did not find expected symbol in ver_matching_test.stdout:
   V1  *sizeof_headers$

Actual output below:
cat: ver_matching_test.stdout: No such file or directory

FAIL: script_test_3.sh (exit: 1)
================================

grep: script_test_3.stdout: No such file or directory
Did not find expected segment in script_test_3.stdout:
   ^  INTERP

Actual output below:
cat: script_test_3.stdout: No such file or directory

FAIL: script_test_4.sh (exit: 1)
================================

grep: script_test_4.stdout: No such file or directory
Did not find expected segment in script_test_4.stdout:
   \.interp[ 	]*PROGBITS[ 	]*0*10000400

Actual output below:
cat: script_test_4.stdout: No such file or directory

FAIL: script_test_5.sh (exit: 1)
================================

grep: script_test_5.stdout: No such file or directory
Did not find expected number (1) of ' .text ' sections in script_test_5.stdout

Actual output below:
cat: script_test_5.stdout: No such file or directory

FAIL: script_test_6.sh (exit: 1)
================================

grep: script_test_6.stdout: No such file or directory
Did not find expected section in script_test_6.stdout:
   \.text[ 	]*PROGBITS[ 	]*0*10001000

Actual output below:
cat: script_test_6.stdout: No such file or directory

FAIL: script_test_7.sh (exit: 1)
================================

grep: script_test_7.stdout: No such file or directory
Did not find expected section in script_test_7.stdout:
   \.interp[ 	]*PROGBITS[ 	]*0*10000100

Actual output below:
cat: script_test_7.stdout: No such file or directory

FAIL: script_test_8.sh (exit: 1)
================================

grep: script_test_8.stdout: No such file or directory
Did not find expected section in script_test_8.stdout:
   \.interp[ 	]*PROGBITS[ 	]*0*20001000

Actual output below:
cat: script_test_8.stdout: No such file or directory

FAIL: script_test_9.sh (exit: 1)
================================

grep: script_test_9.stdout: No such file or directory
Did not find expected section in script_test_9.stdout:
   LOAD .*R E 

Actual output below:
cat: script_test_9.stdout: No such file or directory

FAIL: dynamic_list.sh (exit: 1)
===============================

grep: dynamic_list.stdout: No such file or directory
Did not find expected text in dynamic_list.stdout:
   main

Actual output below:
cat: dynamic_list.stdout: No such file or directory

FAIL: exclude_libs_test.sh (exit: 1)
====================================

grep: exclude_libs_test.syms: No such file or directory
Symbol lib1_default not found.

FAIL: discard_locals_test.sh (exit: 1)
======================================

egrep: discard_locals_test.syms: No such file or directory
egrep: discard_locals_relocatable_test1.syms: No such file or directory
This local symbol is discarded in discard_locals_relocatable_test1.syms:
.LC0

FAIL: hidden_test.sh (exit: 1)
==============================

grep: hidden_test.err: No such file or directory
Did not find expected error in hidden_test.err:
   hidden symbol 'main_hidden' in hidden_test_main.o is referenced by DSO libhidden.so

Actual error output below:
cat: hidden_test.err: No such file or directory

FAIL: retain_symbols_file_test.sh (exit: 1)
===========================================

grep: retain_symbols_file_test.stdout: No such file or directory
Did not find expected symbol t1 in retain_symbols_file_test.stdout

FAIL: strong_ref_weak_def.sh (exit: 1)
======================================

grep: strong_ref_weak_def.stdout: No such file or directory
pattern ".* FUNC.* GLOBAL.* UND.* weak_def" not found in file strong_ref_weak_def.stdout.


FAIL: dyn_weak_ref.sh (exit: 1)
===============================

grep: dyn_weak_ref.stdout: No such file or directory
pattern ".* WEAK .* UND.* weak_ref" not found in file dyn_weak_ref.stdout.


FAIL: memory_test.sh (exit: 1)
==============================

grep: memory_test.stdout: No such file or directory
pattern "  LOAD           0x001000 0x0*02000 0x0*02000 0x0*04 0x0*04 R   0x1000" not found in file memory_test.stdout.


FAIL: script_test_10.sh (exit: 1)
=================================

grep: script_test_10.stdout: No such file or directory
Did not find expected section in script_test_10.stdout:
   .*\[ 1\] .text

Actual output below:
cat: script_test_10.stdout: No such file or directory

FAIL: split_i386.sh (exit: 1)
=============================

could not find 'cmp.*+%gs:[^,]*,%esp' in split_i386_1.stdout

FAIL: exception_static_test (exit: 134)
=======================================


FAIL: initpri2 (exit: 134)
==========================


FAIL: relro_test (exit: 134)
============================

Assertion failed: (0), function f2, file ../../../binutils-2.22/gold/testsuite/relro_test.cc, line 132.

FAIL: relro_now_test (exit: 134)
================================

Assertion failed: (0), function f2, file ../../../binutils-2.22/gold/testsuite/relro_test.cc, line 132.

FAIL: relro_strip_test (exit: 134)
==================================

Assertion failed: (0), function f2, file ../../../binutils-2.22/gold/testsuite/relro_test.cc, line 132.

Re: gold linker 2.22 regressed for DragonFly

[John Marino]

On 1/2/2012 8:47 PM, John Marino wrote:
> On 1/2/2012 8:26 PM, John Marino wrote:
>>
>> Then I tried ">gmake check"
>> It got pretty far in the testsuite, complete through "split_i386.sh" and
>> starting failing at incremental-dump.cc due to numerous missing headers.
>>  I'm got a separate build directory, so the test might not be accounting
>> for that (e.g. source is in {top}/binutils-2.22 and my build directory
>> is {top}/build-b222).
> 
> I just drilled into the testsuite directory and typed ">gmake
> check-TESTS" and went through 137 tests.  DragonFly failed 42 of them
> (attached).
> 
> John.
> 

It appears that many of these 42 failures are false positives.  
There seems to be something wrong with the testsuite makefile.  
If I type something like ">gmake gc_orphan_section_test.stdout" 
then the stdout file is created, and "./gc_orphan_section_test.sh" 
test passes just fine.

For whatever reason, these makefile targets aren't getting run.

I'm also getting several similar error messages like, "
Makefile:2639: warning: overriding recipe for target 'ifuncmain1picstatic'
Makefile:2636: warning: ignoring old recipe for target 'ifuncmain1picstatic'"

John

Re: gold linker 2.22 regressed for DragonFly [revised testsuite results]

[John Marino]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

On 1/2/2012 11:55 PM, John Marino wrote:
> 
> It appears that many of these 42 failures are false positives.  
> There seems to be something wrong with the testsuite makefile.  
> If I type something like ">gmake gc_orphan_section_test.stdout" 
> then the stdout file is created, and "./gc_orphan_section_test.sh" 
> test passes just fine.
> 
> For whatever reason, these makefile targets aren't getting run.
> 
> I'm also getting several similar error messages like, "
> Makefile:2639: warning: overriding recipe for target 'ifuncmain1picstatic'
> Makefile:2636: warning: ignoring old recipe for target 'ifuncmain1picstatic'"
> 
> John

I manually generated all the missing support files and re-ran the testsuite.  
I'm now getting 7 failures out of 137 (log attached).

1. incremental_test:      suspect this is not really an error (failed v2.21 too)
2. ver_matching_test.sh:  __bss_start not local, rtld issue? real issue? (failed on v2.21 too)
3. exception_static_test: likely real problem.  gdb log attached
4. intpri2:               likely real problem.  gdb log attached
5. relro_test:            no relro support in rtld, ignore
6. relro_now_test:        no relro support in rtld, ignore
7. relro_strip_test:      no relro support in rtld, ignore

I'm most worried about tests 3 and 4.
The exception didn't get caught back in exception_test_1.cc.  System compiler is gcc 4.4.7 
(2011-10-25 snapshot) using dl_iterate_phdr for exception handling.
Test 4 may have failed due to the changed ctors setting in option.h ??

Any comment/guidance about the testsuite results is appreciated.
It looks like gold is fairly healthy on DragonFly after altering option.h though.

John

[-- Attachment #2: test-suite.log --]
[-- Type: text/plain, Size: 3155 bytes --]

========================================
   gold 0.1: testsuite/test-suite.log   
========================================

7 of 137 tests failed.  

.. contents:: :depth: 2


FAIL: incremental_test.sh (exit: 1)
===================================

Actual output differs from expected:
diff actual recorded
0a1
> --eh-frame-hdr -dynamic-linker /usr/libexec/ld-elf.so.2 -L/usr/lib/gcc44 -rpath /usr/lib/gcc44 -rpath-link /usr/lib/gcc44 -rpath /usr/lib -rpath-link /usr/lib -o incremental_test /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc44/crtbegin.o incremental_test_1.o incremental_test_2.o -debug -lgcc -lc -lgcc /usr/lib/gcc44/crtend.o /usr/lib/crtn.o

FAIL: ver_matching_test.sh (exit: 1)
====================================

Found unexpected symbol in ver_matching_test.stdout:
   __bss_start

Actual output below:

ver_matching_def.so:     file format elf32-i386

DYNAMIC SYMBOL TABLE:
00001cd1 g    DO .bss	00000001  V2          otherns::stuff
0000078f g    DF .text	00000005  V2          blaza
00000794 g    DF .text	00000005  V2          blaza1
00000754 g    DF .text	00000005  V1          foo
0000075e g    DF .text	00000005  V1          bar()
000007a3 g    DF .text	00000005  V2          blaz
00000768 g    DF .text	00000005  V1          baz(int*)
00000000  w   DF *UND*	00000000              __cxa_finalize
000007a8 g    DF .text	00000005  V2          blazb
00000000  w   D  *UND*	00000000              _Jv_RegisterClasses
00000763 g    DF .text	00000005  Base        bar1()
0000076d g    DF .text	0000000e  Base        baz(int*, char)
0000077b g    DF .text	00000005  Base        baz(char*, int)
00000780 g    DF .text	00000005  V1          bar2
00000785 g    DF .text	00000005  V1          myns::blah()
0000078a g    DF .text	00000005  V1          myns::bip()
0000080c  w   DF .text	00000005  V1          myns::Stuff::Stuff()
00000812  w   DF .text	00000005  Base        Biz::Biz()
00001cd0 g    DO .bss	00000001  Base        otherns::biz
00000799 g    DF .text	00000005  Base        original_blaza2
0000079e g    DF .text	00000005  Base        bla
00001cd4 g    DO .bss	00000004  V1          globaoeufxstuff
00001cd8 g    DO .bss	00000004  Base        globaoeufostuff
00001ca8 g    DO .data	00000004  V1          sizeof_headers
00000000      DF *UND*	00000000              __gxx_personality_v0
00000799 g    DF .text	00000005  V2          blaza2
00001cc8 g    D  *ABS*	00000000  Base        _edata
00001cdc g    D  *ABS*	00000000  Base        _end
00001cc8 g    D  *ABS*	00000000  Base        __bss_start
00000000 g    DO *ABS*	00000000  V1          V1
00000000 g    DO *ABS*	00000000  V2          V2



FAIL: exception_static_test (exit: 134)
=======================================


FAIL: initpri2 (exit: 134)
==========================


FAIL: relro_test (exit: 134)
============================

Assertion failed: (0), function f2, file relro_test.cc, line 132.

FAIL: relro_now_test (exit: 134)
================================

Assertion failed: (0), function f2, file relro_test.cc, line 132.

FAIL: relro_strip_test (exit: 134)
==================================

Assertion failed: (0), function f2, file relro_test.cc, line 132.

[-- Attachment #3: exception_test_failure.log --]
[-- Type: text/plain, Size: 449 bytes --]

#0  0x0806267f in kill ()
#1  0x0805dcb2 in raise ()
#2  0x0805d655 in abort ()
#3  0x0804f96e in uw_init_context_1 ()
#4  0x0804fc37 in _Unwind_RaiseException ()
#5  0x080483ca in __cxa_throw ()
#6  0x08048260 in f1 () at exception_test_2.cc:30
#7  0x0804820b in t1 () at exception_test_1.cc:43
#8  0x080481ce in main () at exception_test_main.cc:33
A debugging session is active.

	Inferior 1 [process 6436] will be killed.

Quit anyway? (y or n) 

[-- Attachment #4: init2pri_failure.log --]
[-- Type: text/plain, Size: 425 bytes --]

#0  0x280f38ff in kill () from /usr/lib/libc.so.7
#1  0x2816f95e in raise () from /usr/lib/libc.so.7
#2  0x2816f1ce in abort () from /usr/lib/libc.so.7
#3  0x080485c3 in ctor1007 () at initpri2.c:55
#4  0x08048628 in __do_global_ctors_aux ()
#5  0x08048312 in _init ()
#6  0x08048411 in _start1 ()
#7  0x08048398 in _start ()
A debugging session is active.

	Inferior 1 [process 10133] will be killed.

Quit anyway? (y or n) 

Re: gold linker 2.22 regressed for DragonFly

[Ian Lance Taylor]

John Marino <binutils@marino.st> writes:

> Editing ld1_LDFLAGS to add --no-ctors-in-init-array is effectively this.
> Also the title of this post is "gold linker 2.22 REGRESSED for
> DragonFly".  gold linker 2.21 doesn't need this switch to build itself.

The --no-ctors-in-init-array option is new for 2.22.  It turns off new
functionality which was added in gold 2.22.  This new functionality only
works on a system which supports the DT_INIT_ARRAY dynamic tag.  My
guess is that DragonFly does not support that.  So, we need to have some
way for the configure script to detect whether DT_INIT_ARRAY works.  We
should be able to use gcc_AC_INITFINI_ARRAY as a model, from
gcc/acinclude.m4.

> I just drilled into the testsuite directory and typed ">gmake
> check-TESTS" and went through 137 tests.  DragonFly failed 42 of them
> (attached).

That doesn't work, you have to run "make check".  That is an automake
thing.

> I'm also getting several similar error messages like, "
> Makefile:2639: warning: overriding recipe for target 'ifuncmain1picstatic'
> Makefile:2636: warning: ignoring old recipe for target 'ifuncmain1picstatic'"

Interesting, this looks like it might be a bug in automake.  The code in
gold/testsuite/Makefile.am is:

if NATIVE_LINKER
if GCC
...
if IFUNC
...
if HAVE_STATIC
if IFUNC_STATIC
...
check_PROGRAMS += ifuncmain1picstatic
ifuncmain1picstatic: ifuncmain1pic.o ifuncmod1.o gcctestdir/ld
	$(LINK) -Bgcctestdir/ -static ifuncmain1pic.o ifuncmod1.o
endif
endif

The corresponding lines in gold/testsuite/Makefile.in, which is
generated by automake, are:

@GCC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) 
...
@HAVE_STATIC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) 
...
@IFUNC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) 
...
@IFUNC_STATIC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) 
...
@NATIVE_LINKER_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) 


It seems to me that automake should only be emitting the rules for
ifuncmain1picstatic$(EXEEXT) if all of the conditions are true.  I don't
know why it is emitting rules if any of the conditions are false.  When
any of the conditions are false, there is no reason to build
ifuncmain1picstatic at all.

Ian

Re: gold linker 2.22 regressed for DragonFly

[John Marino]

On 1/3/2012 8:43 PM, Ian Lance Taylor wrote:
> 
>> I just drilled into the testsuite directory and typed ">gmake
>> check-TESTS" and went through 137 tests.  DragonFly failed 42 of them
>> (attached).
> 
> That doesn't work, you have to run "make check".  That is an automake
> thing.
> 

Hi Ian,
I think you missed my follow-on post which preceded yours:
http://cygwin.com/ml/binutils/2012-01/msg00026.html

By manually generating the support files, I got down to 7 failures,
which I describe in the first post.  Would you mind taking a quick look
at the new test results and provide any comments?

Regards,
John

FYI: Gold v2.22 can now DragonFly world.
However, the boot loader no longer works (a gold v2.21 boot loader
worked).
A gold v2.21 kernel worked, and probably gold 2.22 as well, but neither
version of gold can build kernel modules.  Again, it's a similar loader
problem.  I didn't mention it after v2.21 because I was hoping all the
work for 2.22 would fix it, but I guess I need to open a ticket to
describe the issue so it can be formally examined.

Re: gold linker 2.22 regressed for DragonFly [revised testsuite results]

[Ian Lance Taylor]

John Marino <binutils@marino.st> writes:

> 1. incremental_test:      suspect this is not really an error (failed v2.21 too)

It does pass on GNU/Linux, but it's not an interesting test case at this
point.


> 2. ver_matching_test.sh:  __bss_start not local, rtld issue? real issue? (failed on v2.21 too)

Hard to understand why this would fail.  The __bss_start symbol is
defined automatically by the linker itself.


> 3. exception_static_test: likely real problem.  gdb log attached

My first guess would be that DragonFly does not support dl_iterate_phdr,
or that it does not work correctly for statically linked executables.
That's just a guess, though.


> 4. intpri2:               likely real problem.  gdb log attached

This is almost certainly the same issue as the --no-ctors-in-init-array
issue: DragonFly does not suppor DT_INIT_ARRAY.


> 5. relro_test:            no relro support in rtld, ignore
> 6. relro_now_test:        no relro support in rtld, ignore
> 7. relro_strip_test:      no relro support in rtld, ignore

Yeah, if the dynamic linker does not handle relro, then these tests are
expected to fail.

Ian

Re: gold linker 2.22 regressed for DragonFly [revised testsuite results]

[John Marino]

On 1/5/2012 7:31 PM, Ian Lance Taylor wrote:
>> 2. ver_matching_test.sh:  __bss_start not local, rtld issue? real issue? (failed on v2.21 too)
>
> Hard to understand why this would fail.  The __bss_start symbol is
> defined automatically by the linker itself.

ok.  I thought I remembered seeing references to __bss_start in rtld 
code, so I suspected rtld was the culprit.

>> 3. exception_static_test: likely real problem.  gdb log attached
>
> My first guess would be that DragonFly does not support dl_iterate_phdr,
> or that it does not work correctly for statically linked executables.
> That's just a guess, though.

I brought in dl_iterate_phdr support to dragonfly (system compiler is 
4.4.7 snapshot, 2011-10-25), and it appears to be working although maybe 
in the case of statically linked executables it's not.  What handles the 
latter?  Is that an rtld thing?

>> 4. intpri2:               likely real problem.  gdb log attached
>
> This is almost certainly the same issue as the --no-ctors-in-init-array
> issue: DragonFly does not suppor DT_INIT_ARRAY.

If I wanted to add DT_INIT_ARRAY support to DragonFly, what component 
needs to be updated?  again rtld?

>> 5. relro_test:            no relro support in rtld, ignore
>> 6. relro_now_test:        no relro support in rtld, ignore
>> 7. relro_strip_test:      no relro support in rtld, ignore
>
> Yeah, if the dynamic linker does not handle relro, then these tests are
> expected to fail.
>
> Ian

As far as I can tell, no BSD supports relro and it seems to be of 
limited value so I don't suspect this will change any time soon.

Regards,
John

Re: gold linker 2.22 regressed for DragonFly [revised testsuite results]

[Ian Lance Taylor]

John Marino <binutils@marino.st> writes:

> On 1/5/2012 7:31 PM, Ian Lance Taylor wrote:
>>> 2. ver_matching_test.sh:  __bss_start not local, rtld issue? real issue? (failed on v2.21 too)
>>
>> Hard to understand why this would fail.  The __bss_start symbol is
>> defined automatically by the linker itself.
>
> ok.  I thought I remembered seeing references to __bss_start in rtld
> code, so I suspected rtld was the culprit.

Ideally rtld should not have a publically visible definition of
__bss_start, but I don't see how it would cause a test failure even if
it did.


>>> 3. exception_static_test: likely real problem.  gdb log attached
>>
>> My first guess would be that DragonFly does not support dl_iterate_phdr,
>> or that it does not work correctly for statically linked executables.
>> That's just a guess, though.
>
> I brought in dl_iterate_phdr support to dragonfly (system compiler is
> 4.4.7 snapshot, 2011-10-25), and it appears to be working although
> maybe in the case of statically linked executables it's not.  What
> handles the latter?  Is that an rtld thing?

Statically linked executables don't use rtld at all.  They need to use a
completely different mechanism to get the program segments, typically
just the single set associated with the executable itself.  On GNU/Linux
systems the kernel passes the program segments in the auxiliary vector
using AT_PHDR and AT_PHNUM, and the startup code saves those for use by
dl_iterate_phdr in a static executable.


>>> 4. intpri2:               likely real problem.  gdb log attached
>>
>> This is almost certainly the same issue as the --no-ctors-in-init-array
>> issue: DragonFly does not suppor DT_INIT_ARRAY.
>
> If I wanted to add DT_INIT_ARRAY support to DragonFly, what component
> needs to be updated?  again rtld?

Yes.  Also you need to do some magic for statically linked executables,
taking advantage of the linker-defined symbols __init_array_start and
__init_array_end and friends.


>>> 5. relro_test:            no relro support in rtld, ignore
>>> 6. relro_now_test:        no relro support in rtld, ignore
>>> 7. relro_strip_test:      no relro support in rtld, ignore
>>
>> Yeah, if the dynamic linker does not handle relro, then these tests are
>> expected to fail.
>
> As far as I can tell, no BSD supports relro and it seems to be of
> limited value so I don't suspect this will change any time soon.

I'm surprised that no BSD supports relro as it is a security
enhancement.  I agree that the value is limited but it is not zero.

In my opinion, the biggest advantage is for the PLT.  The PLT must often
be writable when the program starts, so that dynamic relocations can be
applied.  The PLT holds code addresses, so this gives various sorts of
overflow attacks a way to change which code will execute, by overwriting
the PLT.

The point of relro is that after all the PLT relocations have been
applied, there is no need for the PLT to change again.  Making the PLT
be relro implements that: the dynamic linker applies the relocations,
then uses mprotect to make the PLT readonly.

This does of course require that the PLT be fully relocated at program
startup time, rather than using lazy PLT relocations which is the
default behaviour.  You can use the linker option -z now to request that
all PLT relocations be fully relocated at program startup, and when gold
sees -z now it will make the PLT a relro section.

Ian

Re: gold linker 2.22 regressed for DragonFly [revised testsuite results]

[John Marino]

On 1/6/2012 3:42 PM, Ian Lance Taylor wrote:
> John Marino <binutils@marino.st> writes:
> 
>> On 1/5/2012 7:31 PM, Ian Lance Taylor wrote:
>>>> 2. ver_matching_test.sh:  __bss_start not local, rtld issue? real issue? (failed on v2.21 too)
>>>
>>> Hard to understand why this would fail.  The __bss_start symbol is
>>> defined automatically by the linker itself.
>>
>> ok.  I thought I remembered seeing references to __bss_start in rtld
>> code, so I suspected rtld was the culprit.
> 
> Ideally rtld should not have a publically visible definition of
> __bss_start, but I don't see how it would cause a test failure even if
> it did.
> 
> 
>>>> 3. exception_static_test: likely real problem.  gdb log attached
>>>
>>> My first guess would be that DragonFly does not support dl_iterate_phdr,
>>> or that it does not work correctly for statically linked executables.
>>> That's just a guess, though.
>>
>> I brought in dl_iterate_phdr support to dragonfly (system compiler is
>> 4.4.7 snapshot, 2011-10-25), and it appears to be working although
>> maybe in the case of statically linked executables it's not.  What
>> handles the latter?  Is that an rtld thing?
> 
> Statically linked executables don't use rtld at all.  They need to use a
> completely different mechanism to get the program segments, typically
> just the single set associated with the executable itself.  On GNU/Linux
> systems the kernel passes the program segments in the auxiliary vector
> using AT_PHDR and AT_PHNUM, and the startup code saves those for use by
> dl_iterate_phdr in a static executable.
> 
> 
>>>> 4. intpri2:               likely real problem.  gdb log attached
>>>
>>> This is almost certainly the same issue as the --no-ctors-in-init-array
>>> issue: DragonFly does not suppor DT_INIT_ARRAY.
>>
>> If I wanted to add DT_INIT_ARRAY support to DragonFly, what component
>> needs to be updated?  again rtld?
> 
> Yes.  Also you need to do some magic for statically linked executables,
> taking advantage of the linker-defined symbols __init_array_start and
> __init_array_end and friends.
> 
> 
>>>> 5. relro_test:            no relro support in rtld, ignore
>>>> 6. relro_now_test:        no relro support in rtld, ignore
>>>> 7. relro_strip_test:      no relro support in rtld, ignore
>>>
>>> Yeah, if the dynamic linker does not handle relro, then these tests are
>>> expected to fail.
>>
>> As far as I can tell, no BSD supports relro and it seems to be of
>> limited value so I don't suspect this will change any time soon.
> 
> I'm surprised that no BSD supports relro as it is a security
> enhancement.  I agree that the value is limited but it is not zero.
> 
> In my opinion, the biggest advantage is for the PLT.  The PLT must often
> be writable when the program starts, so that dynamic relocations can be
> applied.  The PLT holds code addresses, so this gives various sorts of
> overflow attacks a way to change which code will execute, by overwriting
> the PLT.
> 
> The point of relro is that after all the PLT relocations have been
> applied, there is no need for the PLT to change again.  Making the PLT
> be relro implements that: the dynamic linker applies the relocations,
> then uses mprotect to make the PLT readonly.
> 
> This does of course require that the PLT be fully relocated at program
> startup time, rather than using lazy PLT relocations which is the
> default behaviour.  You can use the linker option -z now to request that
> all PLT relocations be fully relocated at program startup, and when gold
> sees -z now it will make the PLT a relro section.
> 
> Ian

Thanks for your detailed response, Ian.
I try to get smart on these topics and hopefully incorporate some
improvements in DragonFly as a result of this discussion.

Regards,
John

Re: gold linker 2.22 regressed for DragonFly [revised testsuite results]

[John Marino]

On 1/6/2012 9:03 PM, John Marino wrote:
> On 1/6/2012 3:42 PM, Ian Lance Taylor wrote:
>> John Marino<binutils@marino.st>  writes:
>>
>>> On 1/5/2012 7:31 PM, Ian Lance Taylor wrote:
>>>>> 2. ver_matching_test.sh:  __bss_start not local, rtld issue? real issue? (failed on v2.21 too)
>>>>
>>>> Hard to understand why this would fail.  The __bss_start symbol is
>>>> defined automatically by the linker itself.
>>>
>>> ok.  I thought I remembered seeing references to __bss_start in rtld
>>> code, so I suspected rtld was the culprit.
>>
>> Ideally rtld should not have a publically visible definition of
>> __bss_start, but I don't see how it would cause a test failure even if
>> it did.


After many hours of digging into the issue, I might have an explanation 
for why the __bss_start and _edata symbols are getting assigned to the 
dynamic symbol table.  This is the only test that FreeBSD passes and 
DragonFly doesn't, and the reason for that wasn't clear.

Finally using --trace-symbol=__bss_start might have provided a clue.  It 
said __bss_start was defined in libc.so, libm.so, and libstdc++.so.  My 
guess is that the presence of the symbols in those libraries caused gold 
to promote the __bss_start symbol to global.

As for why FreeBSD doesn't have these symbols in their system libraries, 
the difference might be in their use of symbol version maps. 
Unfortunately DragonFly doesn't yet version their library functions, so 
the lack of version scripts means every library has this symbol.

Am I on the right track in diagnosing this test failure?


>>>>> 4. intpri2:               likely real problem.  gdb log attached
>>>>
>>>> This is almost certainly the same issue as the --no-ctors-in-init-array
>>>> issue: DragonFly does not suppor DT_INIT_ARRAY.
>>>
>>> If I wanted to add DT_INIT_ARRAY support to DragonFly, what component
>>> needs to be updated?  again rtld?
>>
>> Yes.  Also you need to do some magic for statically linked executables,
>> taking advantage of the linker-defined symbols __init_array_start and
>> __init_array_end and friends.




I started working to support this.  It also requires new code for crt1 
to handle the main executable.  It's going to take some more work to 
implement this completely.




>>>>> 5. relro_test:            no relro support in rtld, ignore
>>>>> 6. relro_now_test:        no relro support in rtld, ignore
>>>>> 7. relro_strip_test:      no relro support in rtld, ignore
>>>>
>>>> Yeah, if the dynamic linker does not handle relro, then these tests are
>>>> expected to fail.
>>>
>>> As far as I can tell, no BSD supports relro and it seems to be of
>>> limited value so I don't suspect this will change any time soon.
>>
>> I'm surprised that no BSD supports relro as it is a security
>> enhancement.  I agree that the value is limited but it is not zero.
>>
>> In my opinion, the biggest advantage is for the PLT.  The PLT must often
>> be writable when the program starts, so that dynamic relocations can be
>> applied.  The PLT holds code addresses, so this gives various sorts of
>> overflow attacks a way to change which code will execute, by overwriting
>> the PLT.
>>
>> The point of relro is that after all the PLT relocations have been
>> applied, there is no need for the PLT to change again.  Making the PLT
>> be relro implements that: the dynamic linker applies the relocations,
>> then uses mprotect to make the PLT readonly.
>>
>> This does of course require that the PLT be fully relocated at program
>> startup time, rather than using lazy PLT relocations which is the
>> default behaviour.  You can use the linker option -z now to request that
>> all PLT relocations be fully relocated at program startup, and when gold
>> sees -z now it will make the PLT a relro section.
>>
>> Ian


I came up with an initial implementation of relro for the dynamic linker 
and FreeBSD's Konstantin Belousov reviewed and added to it.  Now 
DragonFly passes these three tests and I think there's a good chance 
that code will get incorporated into FreeBSD as well.

John

Re: gold linker 2.22 regressed for DragonFly [revised testsuite results]

[Ian Lance Taylor]

John Marino <dragonflybsd@marino.st> writes:

>>> Ideally rtld should not have a publically visible definition of
>>> __bss_start, but I don't see how it would cause a test failure even if
>>> it did.
>
>
> After many hours of digging into the issue, I might have an
> explanation for why the __bss_start and _edata symbols are getting
> assigned to the dynamic symbol table.  This is the only test that
> FreeBSD passes and DragonFly doesn't, and the reason for that wasn't
> clear.
>
> Finally using --trace-symbol=__bss_start might have provided a clue.
> It said __bss_start was defined in libc.so, libm.so, and libstdc++.so.
> My guess is that the presence of the symbols in those libraries caused
> gold to promote the __bss_start symbol to global.
>
> As for why FreeBSD doesn't have these symbols in their system
> libraries, the difference might be in their use of symbol version
> maps. Unfortunately DragonFly doesn't yet version their library
> functions, so the lack of version scripts means every library has this
> symbol.
>
> Am I on the right track in diagnosing this test failure?

Sounds like it.  There may be a target independent problem here. What
should the linker do if the version script specifies that a symbol is
local but the symbol is also defined in a shared library?  I think it
has to make the symbol local despite the definitions, but it sounds like
that is not happening.


> I came up with an initial implementation of relro for the dynamic
> linker and FreeBSD's Konstantin Belousov reviewed and added to it.
> Now DragonFly passes these three tests and I think there's a good
> chance that code will get incorporated into FreeBSD as well.

Cool.

Ian

Re: gold linker 2.22 regressed for DragonFly [revised testsuite results]

[John Marino]

On 1/22/2012 8:43 PM, Ian Lance Taylor wrote:
>
> Sounds like it.  There may be a target independent problem here. What
> should the linker do if the version script specifies that a symbol is
> local but the symbol is also defined in a shared library?  I think it
> has to make the symbol local despite the definitions, but it sounds like
> that is not happening.

Are you planning to independently verify and modify the linker behavior 
if confirmed?  From my point of view, there's nothing more to be done 
now that the situation is understood.

John

Re: gold linker 2.22 regressed for DragonFly [revised testsuite results]

[Ian Lance Taylor]

John Marino <dragonflybsd@marino.st> writes:

> On 1/22/2012 8:43 PM, Ian Lance Taylor wrote:
>>
>> Sounds like it.  There may be a target independent problem here. What
>> should the linker do if the version script specifies that a symbol is
>> local but the symbol is also defined in a shared library?  I think it
>> has to make the symbol local despite the definitions, but it sounds like
>> that is not happening.
>
> Are you planning to independently verify and modify the linker
> behavior if confirmed?  From my point of view, there's nothing more to
> be done now that the situation is understood.

I suppose I will take a look at it at some point.

Ian