[Bug binutils/4797] New: SEGV fault due to NULL pointer deref in dwarf2.c

[dougkwan at google dot com]

nm -l crashes because of a NULL pointer deref in dwarf2.c. functionname_ptr can
be NULL and there are tests in the logic of the function find_line to deal with
that case. Yet, in line 2383 of current top, functionname_ptr is dereference
without check for NULL.

The fix is to check for NULL before using functionname_ptr. I tried a one-line
fix and it seems to work.

-- 
   Summary: SEGV fault due to NULL pointer deref in dwarf2.c
   Product: binutils
   Version: 2.18 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: dougkwan at google dot com
CC: bug-binutils at gnu dot org
 GCC build triplet: i686-linux-gnu
  GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu


http://sourceware.org/bugzilla/show_bug.cgi?id=4797

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/4797] SEGV fault due to NULL pointer deref in dwarf2.c

[dougkwan at google dot com]

--- Additional Comments From dougkwan at google dot com  2007-07-16 23:38 
---
Created an attachment (id=1918)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=1918&action=view)
Proposed fix for SEGV problem in dwarf2.c

Tested this patch in i686-linux-gnu. Looked okay.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4797

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/13362] internal error in value_from_output_section, at ../../gold/reloc.cc:1549 on armel

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13362

Doug Kwan  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

--- Comment #4 from Doug Kwan  2011-10-31 20:20:43 
UTC ---
I am looking at it.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/13362] internal error in value_from_output_section, at ../../gold/reloc.cc:1549 on armel

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13362

--- Comment #5 from Doug Kwan  2011-11-01 21:24:49 
UTC ---
(In reply to comment #4)
> I am looking at it.

This is a different problem than bug 12771,  which happened in the ARM backend.
 The problem here is that relocate_for_relocatable does does not handle
unaligned accesses properly.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/13362] internal error in value_from_output_section, at ../../gold/reloc.cc:1549 on armel

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13362

--- Comment #9 from Doug Kwan  2011-11-10 05:26:10 
UTC ---
I think there are still problems.  I had problem reproducing this on a
Pandaboard but I will try adding an assert in rel to see if I can
catch all problems.

-Doug

On Wed, Nov 9, 2011 at 8:09 PM, jrnieder at gmail dot com
 wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=13362
>
> --- Comment #8 from Jonathan Nieder  2011-11-10 
> 04:09:30 UTC ---
> Jonathan Nieder wrote:
>
>> | $ make check
>> [...]
>> | g++ -W -Wall    -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
>> -fmerge-constants -g -O2 -Bgcctestdir/  -o tls_test tls_test.o 
>> tls_test_file2.o tls_test_main.o tls_test_c.o -lpthread -lz
>> | collect2: ld terminated with signal 7 [Bus error]
>
> More precisely:
>
> | Program received signal SIGBUS, Bus error.
> | 0x000841ac in rel<32> (value=32, view=0x2eb938 "0.,") at reloc.h:333
> | 333         elfcpp::Swap::writeval(wv, x + value);
>
> Backtrace:
>
>  #0  rel<32> at reloc.h:333
>  #1  rel32 at reloc.h:569
>  #2  relocate_tls at arm.cc:9376
>  #3  (anonymous namespace)::Target_arm::Relocate::relocate at
>       arm.cc:9256
>  #4  relocate_section<32, false, {anonymous}::Target_arm, 9,
> {anonymous}::Target_arm::Relocate>
>       at target-reloc.h:385
>  #5  (anonymous namespace)::Target_arm::relocate_section at arm.cc:9478
>  #6  gold::Sized_relobj_file<32, false>::do_relocate_sections at reloc.cc:1013
>  #7  (anonymous namespace)::Arm_relobj::do_relocate_sections
>       at arm.cc:6471
>  #8  relocate_sections at object.h:2337
>  #9  gold::Sized_relobj_file<32, false>::do_relocate at reloc.cc:670
>  #10  relocate at object.h:1074
>  #11  gold::Relocate_task::run at reloc.cc:239
>  #12  gold::Workqueue::find_and_run_task at workqueue.cc:319
>
> Worth a separate report?
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
>

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/13320] Please support thumb entry points in PLT instead of using (more or less randomly located) stubs

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13320

--- Comment #3 from Doug Kwan  2011-12-02 19:23:56 
UTC ---
Thanks for working on this.  You can run the test suite using QEMU, it
is slow but it does the job.  You do need to treat one of test case
because it has too many sections that gold runs out of simulated
memory.  One caveat is that QEMU does not catch unaligned accesses, we
had bugs due to unaligned accesses in the past.  Incremental linking
never works on ARM, BTW.

I will take a look at your patch.

-Doug

On Fri, Dec 2, 2011 at 11:03 AM, froydnj at gmail dot com
 wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=13320
>
> --- Comment #2 from Nathan Froyd  2011-12-02 
> 19:03:11 UTC ---
> Created attachment 6087
>  --> http://sourceware.org/bugzilla/attachment.cgi?id=6087
> working patch, no incremental linker support
>
> Here's a patch that gets things going; it works on several testcases I've
> tried.  I haven't run the test suite yet due to native testing requirements
> yet, but I have tested a wide range of branch distances and such and things
> look pretty good.
>
> I'm also fairly certain this breaks when doing incremental linking.  Stubs are
> now variable-sized when using this scheme, and the incremental linking support
> is not yet (ever?) ready to handle that.  Making all stubs 16 bytes when using
> the incremental linking support is a possibility.
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are the assignee for the bug.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/13320] Please support thumb entry points in PLT instead of using (more or less randomly located) stubs

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13320

--- Comment #5 from Doug Kwan  2011-12-02 20:42:21 
UTC ---
ubuntu karmic.  I wish I could use QEMU linux-user but I right now I
had to use the system emulator.

On Fri, Dec 2, 2011 at 12:14 PM, froydnj at gmail dot com
 wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=13320
>
> Nathan Froyd  changed:
>
>           What    |Removed                     |Added
> 
>                 CC|                            |froydnj at gmail dot com
>
> --- Comment #4 from Nathan Froyd  2011-12-02 
> 20:14:50 UTC ---
> I was trying to set things up inside a QEMU VM, but was running into problems
> because Debian 5.0 uses deprecated relocations that gold does not support.
> What distribution are you using?  Or do you have clever hacks that enable
> running the testsuite with the QEMU linux-user support?
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are the assignee for the bug.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/15200] Runtime undefined reference to __exidx_start/_end

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15200

--- Comment #4 from Doug Kwan  2013-03-07 04:04:35 
UTC ---
The symbols __exidx_end & __exidx_start were exported incorrectly in
the past.  This is fixed in both ld & gold in the sense that these
symbols are defined by not exported.  I think defining these symbols
when there is a non-weak definition in a DSO is not the right thing to
do.  This is basically multiple definition and usually is an error.
I am not working on the Android NDK so I can't give you a good
suggestion here.  Does using the latest NDK fixes your problem?

On Wed, Mar 6, 2013 at 6:39 PM, petechou at gmail dot com
 wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=15200
>
> --- Comment #3 from pete  2013-03-07 02:39:59 UTC 
> ---
> Hello,
>
> Let me describe this issue again. The runtime undefined reference is because:
>
> 1. Using ld.gold to link against libraries (say libc.so) in android ndk-r8, 
> and
> those libraries are probably generated by ld.bfd.
>
> $ readelf -s /tmp/android-ndk-r8/platforms/android-14/arch-arm/usr/lib/libc.so
> | grep exidx
>106: cf44 0 NOTYPE  GLOBAL DEFAULT  ABS __exidx_end
>334: cf44 0 NOTYPE  GLOBAL DEFAULT  ABS __exidx_start
>730: 89a820 FUNCGLOBAL DEFAULT4 __gnu_Unwind_Find_exidx
>118: cf44 0 NOTYPE  GLOBAL DEFAULT  ABS __exidx_end
>346: cf44 0 NOTYPE  GLOBAL DEFAULT  ABS __exidx_start
>742: 89a820 FUNCGLOBAL DEFAULT4 __gnu_Unwind_Find_exidx
>
> 2. Running the library on a newer version (say 4.2) of Android system, and
> there are no __exidx_start/_end symbols in the libraries, e.g, libc.so.
>
> $ readelf -s $AOSP/out/target/product/generic/system/lib/libc.so | grep exidx
>882: e929 4 FUNCGLOBAL DEFAULT7 __gnu_Unwind_Find_exidx
>891:  0 FUNCGLOBAL DEFAULT  UND dl_unwind_find_exidx
>
> So, it's fine to generate dynamic relocations for undefined symbols, but I
> think section/segment symbols in output probably should be defined locally
> anyway, if we're going to define them. Using section/segment definition in
> DT_NEEDED doesn't seem to be the correct behavior?
>
> BTW, I also checked ld.bfd also defines __exidx_start/_end locally.
>
> $ arm-linux-androideabi-ld.bfd -shared -o libplasma.so plasma.o libc.so
> $ readelf -s libplasma.so | grep exidx
>  3: 3980 0 NOTYPE  LOCAL  DEFAULT  ABS __exidx_end
>  4: 3858 0 NOTYPE  LOCAL  DEFAULT  ABS __exidx_start
> 64:  0 FUNCWEAK   DEFAULT  UND __gnu_Unwind_Find_exidx
>119: 3980 0 NOTYPE  LOCAL  DEFAULT  ABS __exidx_end
>121: 3858 0 NOTYPE  LOCAL  DEFAULT  ABS __exidx_start
>185:  0 FUNCWEAK   DEFAULT  UND __gnu_Unwind_Find_exidx
>
> Any comment about the issue and the patch?
>
> -
> Thanks,
> Pete
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/15200] Runtime undefined reference to __exidx_start/_end

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15200

--- Comment #6 from Doug Kwan  2013-03-07 05:42:20 
UTC ---
The symbols do not have same visibility.  gold in general is
compatible with GNU ld.  If you look at src/ld/emulparams/, you will
set that the __bss symbols are exported but the __exidx symbols are
defined hidden.  gold matches the behaviour of ld.  If you look at
defstd.cc in gold, you will again see that some of these symbols are
hidden but some are not.

-Doug


On Wed, Mar 6, 2013 at 9:31 PM, petechou at gmail dot com
 wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=15200
>
> --- Comment #5 from pete  2013-03-07 05:31:25 UTC 
> ---
> (In reply to comment #4)
>> The symbols __exidx_end & __exidx_start were exported incorrectly in
>> the past.  This is fixed in both ld & gold in the sense that these
>> symbols are defined by not exported.  I think defining these symbols
>> when there is a non-weak definition in a DSO is not the right thing to
>> do.  This is basically multiple definition and usually is an error.
>
> If so, all section/segment symbols should be defined (if needed) by not
> exported?
>
> But when there is a non-weak definition in a DSO, it's still possible to find
> ld.gold define and export segment symbols like __bss_start (See
> gold.defstd.cc:214. only_if_ref is set to false). And there is no multiple
> definition error.
>
> $ readelf -Ds libc.so | grep __bss_start
>   268 311: d898 0 NOTYPE  GLOBAL DEFAULT ABS __bss_start__
>   619 470: d898 0 NOTYPE  GLOBAL DEFAULT ABS __bss_start
>
> $ arm-linux-androideabi-ld.gold -shared -o libplasma.so plasma.o libc.so
>
> $ readelf -s libplasma.so | grep __bss_start
> 73: 4148 0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start
>168: 4148 0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start
>
>> I am not working on the Android NDK so I can't give you a good
>> suggestion here.  Does using the latest NDK fixes your problem?
>>
>
> Yes, there is no this issue with the latest NDK.
>
> -
> Thanks,
> Pete
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/15200] Runtime undefined reference to __exidx_start/_end

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15200

--- Comment #8 from Doug Kwan  2013-03-07 08:10:16 
UTC ---
Hi Pete,

1. My concern of your patch is that it affects all targets, not just
ARM.  While it may fix the problem on ARM, I cannot speak for authors
of other backends.
2. I am don't have power approve a patch, you need to convince Ian
Taylor that this is the right thing to do for all targets.
3. This bug only happens when DSOs incorrectly export __exidx_start &
__exidx_end.  These DSOs are considered broken and I strongly
recommend you moving to a newer NDK version with DSOs that have proper
visibility.  Both ld & gold no longer export these symbols.  The
reason for not exporting is explained here in the ld patch:

http://sourceware.org/ml/binutils/2009-11/msg00367.html

-Doug


On Wed, Mar 6, 2013 at 10:43 PM, petechou at gmail dot com
 wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=15200
>
> --- Comment #7 from pete  2013-03-07 06:43:08 UTC 
> ---
> I can think visibility does matter, but only for exporting the symbol or not.
> In the previous case, gold does define the __bss symbols but not use the
> definition in DSO, so I think we should still define section/segment symbols
> locally.
>
> -Pete
>
> (In reply to comment #6)
>> The symbols do not have same visibility.  gold in general is
>> compatible with GNU ld.  If you look at src/ld/emulparams/, you will
>> set that the __bss symbols are exported but the __exidx symbols are
>> defined hidden.  gold matches the behaviour of ld.  If you look at
>> defstd.cc in gold, you will again see that some of these symbols are
>> hidden but some are not.
>>
>> -Doug
>>
>>
>> On Wed, Mar 6, 2013 at 9:31 PM, petechou at gmail dot com
>>  wrote:
>> > http://sourceware.org/bugzilla/show_bug.cgi?id=15200
>> >
>> > --- Comment #5 from pete  2013-03-07 05:31:25 
>> > UTC ---
>> > (In reply to comment #4)
>> >> The symbols __exidx_end & __exidx_start were exported incorrectly in
>> >> the past.  This is fixed in both ld & gold in the sense that these
>> >> symbols are defined by not exported.  I think defining these symbols
>> >> when there is a non-weak definition in a DSO is not the right thing to
>> >> do.  This is basically multiple definition and usually is an error.
>> >
>> > If so, all section/segment symbols should be defined (if needed) by not
>> > exported?
>> >
>> > But when there is a non-weak definition in a DSO, it's still possible to 
>> > find
>> > ld.gold define and export segment symbols like __bss_start (See
>> > gold.defstd.cc:214. only_if_ref is set to false). And there is no multiple
>> > definition error.
>> >
>> > $ readelf -Ds libc.so | grep __bss_start
>> >   268 311: d898 0 NOTYPE  GLOBAL DEFAULT ABS __bss_start__
>> >   619 470: d898 0 NOTYPE  GLOBAL DEFAULT ABS __bss_start
>> >
>> > $ arm-linux-androideabi-ld.gold -shared -o libplasma.so plasma.o libc.so
>> >
>> > $ readelf -s libplasma.so | grep __bss_start
>> > 73: 4148 0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start
>> >168: 4148 0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start
>> >
>> >> I am not working on the Android NDK so I can't give you a good
>> >> suggestion here.  Does using the latest NDK fixes your problem?
>> >>
>> >
>> > Yes, there is no this issue with the latest NDK.
>> >
>> > -
>> > Thanks,
>> > Pete
>> >
>> > --
>> > Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
>> > --- You are receiving this mail because: ---
>> > You are on the CC list for the bug.
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/15200] Runtime undefined reference to __exidx_start/_end

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15200

--- Comment #10 from Doug Kwan  2013-03-13 03:57:35 
UTC ---
I have no object to what is proposed but the decision is Ian's.

On Tue, Mar 12, 2013 at 7:03 PM, petechou at gmail dot com
 wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=15200
>
> --- Comment #9 from pete  2013-03-13 02:03:32 UTC 
> ---
> If there is a libfoo.so, it's possible to implement part of functions in
> libfoo.so and then link against libfoo.so again to produce a new library. I
> think the "linker-defined" symbols should also have higher priority than the
> symbols in DSO.
>
> And I also think we should have the same behavior on defining symbol value
> whether only_if_ref is set or not?
>
> The patch will affect 4 ways to define output symbols:
> 1. do_define_in_output_data
> 2. do_define_in_output_segment
> 3. do_define_as_constant
> 4. add_undefined_symbol_from_command_line
>
> For 1, 2, and 3, it makes sense to use the given output section, segment, and
> constant to define symbol values if the "linker-defined" symbols have higher
> priority.
>
> As for 4, I think it doesn't matter.
>
> -
> Thanks,
> Pete
>
> (In reply to comment #8)
>> Hi Pete,
>>
>> 1. My concern of your patch is that it affects all targets, not just
>> ARM.  While it may fix the problem on ARM, I cannot speak for authors
>> of other backends.
>> 2. I am don't have power approve a patch, you need to convince Ian
>> Taylor that this is the right thing to do for all targets.
>> 3. This bug only happens when DSOs incorrectly export __exidx_start &
>> __exidx_end.  These DSOs are considered broken and I strongly
>> recommend you moving to a newer NDK version with DSOs that have proper
>> visibility.  Both ld & gold no longer export these symbols.  The
>> reason for not exporting is explained here in the ld patch:
>>
>> http://sourceware.org/ml/binutils/2009-11/msg00367.html
>>
>> -Doug
>>
>>
>> On Wed, Mar 6, 2013 at 10:43 PM, petechou at gmail dot com
>>  wrote:
>> > http://sourceware.org/bugzilla/show_bug.cgi?id=15200
>> >
>> > --- Comment #7 from pete  2013-03-07 06:43:08 
>> > UTC ---
>> > I can think visibility does matter, but only for exporting the symbol or 
>> > not.
>> > In the previous case, gold does define the __bss symbols but not use the
>> > definition in DSO, so I think we should still define section/segment 
>> > symbols
>> > locally.
>> >
>> > -Pete
>> >
>> > (In reply to comment #6)
>> >> The symbols do not have same visibility.  gold in general is
>> >> compatible with GNU ld.  If you look at src/ld/emulparams/, you will
>> >> set that the __bss symbols are exported but the __exidx symbols are
>> >> defined hidden.  gold matches the behaviour of ld.  If you look at
>> >> defstd.cc in gold, you will again see that some of these symbols are
>> >> hidden but some are not.
>> >>
>> >> -Doug
>> >>
>> >>
>> >> On Wed, Mar 6, 2013 at 9:31 PM, petechou at gmail dot com
>> >>  wrote:
>> >> > http://sourceware.org/bugzilla/show_bug.cgi?id=15200
>> >> >
>> >> > --- Comment #5 from pete  2013-03-07 
>> >> > 05:31:25 UTC ---
>> >> > (In reply to comment #4)
>> >> >> The symbols __exidx_end & __exidx_start were exported incorrectly in
>> >> >> the past.  This is fixed in both ld & gold in the sense that these
>> >> >> symbols are defined by not exported.  I think defining these symbols
>> >> >> when there is a non-weak definition in a DSO is not the right thing to
>> >> >> do.  This is basically multiple definition and usually is an error.
>> >> >
>> >> > If so, all section/segment symbols should be defined (if needed) by not
>> >> > exported?
>> >> >
>> >> > But when there is a non-weak definition in a DSO, it's still possible 
>> >> > to find
>> >> > ld.gold define and export segment symbols like __bss_start (See
>> >> > gold.defstd.cc:214. only_if_ref is set to false). And there is no 
>> >> > multiple
>> >> > definition error.
>> >> >
>> >> > $ readelf -Ds libc.so | grep __bss_start
>> >> >   268 311: d898 0 NOTYPE  GLOBAL DEFAULT ABS __bss_start__
>> >> >   619 470: d898 0 NOTYPE  GLOBAL DEFAULT ABS __bss_start
>> >> >
>> >> > $ arm-linux-androideabi-ld.gold -shared -o libplasma.so plasma.o libc.so
>> >> >
>> >> > $ readelf -s libplasma.so | grep __bss_start
>> >> > 73: 4148 0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start
>> >> >168: 4148 0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start
>> >> >
>> >> >> I am not working on the Android NDK so I can't give you a good
>> >> >> suggestion here.  Does using the latest NDK fixes your problem?
>> >> >>
>> >> >
>> >> > Yes, there is no this issue with the latest NDK.
>> >> >
>> >> > -
>> >> > Thanks,
>> >> > Pete
>> >> >
>> >> > --
>> >> > Configure bugmail: 
>> >> > http://sourceware.org/bugzilla/userprefs.cgi?tab=email
>> >> > --- You are receiving this mail because: ---
>> >> > You are on the CC list for the bug.
>> >
>> > --
>> > Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
>> > --

[Bug gold/15200] Runtime undefined reference to __exidx_start/_end

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15200

--- Comment #14 from Doug Kwan  2013-03-20 04:41:03 
UTC ---
The special symbols in question __exidx_{start,end} were exported from
DSO's by mistake in both ld & gold and the mistake has been fixed in
both linkers.  We really don't want references of such symbols in the
main executable to be bound to the definitions in a DSO.  So Peter
wants to define those symbols even when they are seen in a DSO.  Doing
so makes it possible to use DSO's generated by older versions of gold
& ld on ARM but I really don't know whether this affects correctness
in general.

-Doug

On Tue, Mar 19, 2013 at 8:29 PM, ian at airs dot com
 wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=15200
>
> --- Comment #12 from Ian Lance Taylor  2013-03-20 
> 03:29:49 UTC ---
> oldsym->in_dyn() will return true if the symbol was seen in a dynamic object.
> I don't see why we should create the symbol if it is seen in a dynamic object.
>
> It seems that the code should be something like
>
> if (oldsym == NULL)
>   return NULL;
> if (oldsym->is_undefined())
>   ;
> else if (oldsym->is_from_dynobj())
>   ;
> else
>   return NULL;
>
> but that's not right either.  We should only create the symbol if it is
> referenced by a regular object.  So it really needs to be
>
> if (oldsym == NULL)
>   return NULL;
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/18878] New: _savegpr1_XXX crashes when called through a stub on POWERPC64LE

[dougkwan at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18878

Bug ID: 18878
   Summary: _savegpr1_XXX crashes when called through a stub on
POWERPC64LE
   Product: binutils
   Version: 2.24
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: dougkwan at google dot com
  Target Milestone: ---

Created attachment 8556
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8556&action=edit
test case for bug

I have found problem in which a big powerpc64le binary crashes when compiled
with -Os.  I chased down the root cause to be calling runtime functions
_savegpr1_XXX via branch stubs.  These functions do not follow the normal ABI
and take the value of r12 as the argument.  Unfortunately, branch stubs and
PLTs also use r12 as a scratch register during address calculation.  So the
stubs clobber the argument to _savegpr1_XXX and cause SEGV faults.

Attached is a test case. I tried it on a POWER8 machine running ubuntu.  The
test crashes if compiled with -Os using both ld and gold.

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/4.8/lto-wrapper
Target: powerpc64le-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--disable-libsanitizer --disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-ppc64el/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-ppc64el
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-ppc64el
--with-arch-directory=ppc64el --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-secureplt --with-cpu=power7 --with-tune=power8
--disable-multilib --enable-multiarch --disable-werror --with-long-double-128
--enable-checking=release --build=powerpc64le-linux-gnu
--host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/18878] _savegpr1_XXX crashes when called through a stub on POWERPC64LE

[dougkwan at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18878

Doug Kwan  changed:

   What|Removed |Added

 Target||powerpc64le-linux-gnu
   Host||powerpc64le-linux-gnu
  Build||powerpc64le-linux-gnu

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/18878] _savegpr1_XXX crashes when called through a stub on POWERPC64LE

[dougkwan at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18878

Doug Kwan  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/11247] Assert failure in arm.cc

[dougkwan at google dot com]

--- Additional Comments From dougkwan at google dot com  2010-02-04 19:47 
---
Can you try this patch and send me back the error message?

Index: arm.cc
===
RCS file: /cvs/src/src/gold/arm.cc,v
retrieving revision 1.76
diff -u -u -p -r1.76 arm.cc
--- arm.cc  4 Feb 2010 03:32:18 -   1.76
+++ arm.cc  4 Feb 2010 19:44:50 -
@@ -5654,6 +5654,16 @@ Arm_relobj::scan_sections_fo
  const Output_relaxed_input_section* poris =
  out_sections[index]->find_relaxed_input_section(this, index);
  gold_assert(poris != NULL);
+ if (poris == NULL)
+   {
+ printf("found bad section %s (index %u) in %s\n",
+this->section_name(index).c_str(), index,
+this->name().c_str());
+ const elfcpp::Shdr<32, big_endian> shdr(pshdrs + index);
+ printf("section type=%u section flag=%u\n",
+shdr.get_sh_type(), shdr.get_sh_flags());
+ gold_unreachable();
+   }
  output_address = poris->address();
}




-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11247

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/11247] Assert failure in arm.cc

[dougkwan at google dot com]

--- Additional Comments From dougkwan at google dot com  2010-02-04 22:09 
---
Patch for build breakage submitted in

http://sourceware.org/ml/binutils/2010-02/msg00070.html

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11247

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/11247] Assert failure in arm.cc

[dougkwan at google dot com]

--- Additional Comments From dougkwan at google dot com  2010-02-05 00:34 
---
The build breakage has been fixed but we still need to fix the assertion.  I
built Qt-4.6.1 for arm-unknown-linux-gnu using gold as the linker but did not
see the assertion.  I am trying again using the "-march=armv-7a" options to see
if this is related to ARM v7.   

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11247

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/11247] Assert failure in arm.cc

[dougkwan at google dot com]

--- Additional Comments From dougkwan at google dot com  2010-02-05 17:56 
---
Subject: Re:  Assert failure in arm.cc

2010/2/5 ahartmetz at gmail dot com :

> I've updated bintuils to the latest CVS version and applied the patch (I 
> removed
> the assert before the debug output though ;)
> The output is:
> found bad section .eh_frame (index 14) in obj/release/pcre_compile.o
> section type=0 section flag=0
> /usr/bin/ld: internal error in scan_sections_for_stubs, at arm.cc:5664
> collect2: ld returned 1 exit status
> make[1]: *** [../../lib/libQtScript.so.4.6.1] Error 1
> make[1]: Leaving directory `/mnt/swap/kde/kde-qt/src/script'
> make: *** [sub-script-make_default-ordered] Error 2
>
> As the error might be related to Thumb-2 code it might be of interest that
> rgular expressions and JavaScript are just-in-time compiled in WebKit, and the
> JIT compiler seems to use Thumb(-2) via stubs written in Assembly, unlike the
> regularly compiled rest.

It's not THUMB-2 related.  The EH_FRAME sections are special and
should not be subject to any stub-scanning,  I just need to skip them.
 Thanks for the information.

-Doug


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11247

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/11247] Assert failure in arm.cc

[dougkwan at google dot com]

--- Additional Comments From dougkwan at google dot com  2010-02-06 04:31 
---
I added code to avoid stub scanning for merged sections.   This should fix your
problem.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=11247

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/11718] GOLD produces nonworking Linux shared librarys

[dougkwan at google dot com]

--- Additional Comments From dougkwan at google dot com  2010-08-03 20:11 
---
Your testcase needs other libraries.  Can you attached two copies of 
eina_chained_mempool.so, one linked with gold and the ld?

(In reply to comment #0)
> I'm try build modules for eina:
>  
> arm-as eina_chained_mempool.s -o chain.o
> arm-ld chain.o --eh-frame-hdr -shared -dynamic-linker /lib/ld-linux.so.3 -X -m
> armelf_linux_eabi -o
> ./shared/build/eina/src/modules/mp/chained_pool/.libs/eina_chained_mempool.so
> /usr/lib/crti.o /usr/lib/gcc/arm-linux-gnueabi/4.3.2/crtbeginS.o
> -L/home/kursh/arm/arm-linux-gnueabi/lib -L/home/kursh/arm/evas/shared/run/lib
> -L/usr/lib/gcc/arm-linux-gnueabi/4.3.2
> -L/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/lib -
L/lib
> -L/usr/lib -rpath /home/kursh/arm/evas/shared/run/lib -leina -ldl -lrt -lm
> -soname eina_chained_mempool.so -lgcc --as-needed -lgcc_s --no-as-needed
> -lpthread -lc -lgcc --as-needed -lgcc_s --no-as-needed
> /usr/lib/gcc/arm-linux-gnueabi/4.3.2/crtendS.o /usr/lib/crtn.o
> 
> A shared library linked with gold (GNU Binutils 2.20.51.20100618) causes
> segmentation fault, because GOT entry for some function is zero, while shared
> library linked not gold version ld, all work fine.
> Gdb says:
> 0x in ?? ()
> (gdb) bt
> #0  0x in ?? ()
> #1  0x40023edc in _GLOBAL_OFFSET_TABLE_ () from 
/home/.../eina_chained_mempool.so
> 
> Bug maybe related to PR 11172.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11718

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/12826] [PATCH] Gold not knowing ARM7EM architecture

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12826

Doug Kwan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Doug Kwan  2011-06-01 20:03:03 
UTC ---
This is fixed in trunk.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/12771] internal error in value_from_output_section, at ../../gold/reloc.cc:1508 on armel

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12771

--- Comment #9 from Doug Kwan  2011-06-30 06:51:00 
UTC ---
Thanks for fix that.  I will submit a patch later to convert to
unaligned swaps as needed.

-Doug

On Wed, Jun 29, 2011 at 11:01 PM, ian at airs dot com
 wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=12771
>
> Ian Lance Taylor  changed:
>
>           What    |Removed                     |Added
> 
>             Status|RESOLVED                    |REOPENED
>                 CC|                            |dougkwan at google dot com,
>                   |                            |ian at airs dot com
>         Resolution|WORKSFORME                  |
>
> --- Comment #8 from Ian Lance Taylor  2011-06-30 
> 06:00:32 UTC ---
> OK, I looked at this a bit more.  It's possible that this is being caused by 
> an
> unaligned access.  I see that on ARM an unaligned access will load rotated
> bytes.  Does this happen on the emulator?
>
> This object file has unaligned R_ARM_ABS32 relocations against the .debug_info
> section.  When the linker fetches the addend for those relocations, it will do
> an unaligned read.
>
> Try changing the function Arm_relocate_functions::abs32 around line 3284 of
> arm.cc to this:
>
>  // R_ARM_ABS32: (S + A) | T
>  static inline typename This::Status
>  abs32(unsigned char* view,
>    const Sized_relobj_file<32, big_endian>* object,
>    const Symbol_value<32>* psymval,
>    Arm_address thumb_bit)
>  {
>    typedef typename elfcpp::Swap<32, big_endian>::Valtype Valtype;
>    Valtype addend = elfcpp::Swap_unaligned<32, big_endian>::readval(view);
>    Valtype x = psymval->value(object, addend) | thumb_bit;
>    elfcpp::Swap_unaligned<32, big_endian>::writeval(view, x);
>    return This::STATUS_OKAY;
>  }
>
> If that change fixes the crash, then it is indeed an unaligned access problem.
>
> The ARM ELF ABI does suggest that there is no required alignment for
> relocations, so it does seem that much of the code in Arm_relocation_functions
> needs to use Swap_unaligned rather than Swap.
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
>

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/12565] NOLOAD sections empty

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12565

--- Comment #11 from Doug Kwan  2011-06-30 18:24:45 
UTC ---
The ARM linux kernel also uses NOLOAD.  I added support for that in
gold to link the kernel.

-Doug

On Thu, Jun 30, 2011 at 9:07 AM, Ian Lance Taylor  wrote:
> Nick Clifton  writes:
>
>> I have been looking at PR 12565, and I have to say that I do not
>> understand the linker's behaviour for NOLOAD sections on ELF based
>> targets.  What is the point of having a section that cannot be loaded
>> and that does not have any contents ?
>>
>> Also, as far as I can see, this behaviour is not documented
>> anywhere. Do you know of any applications that rely upon this feature
>> ?
>
> If you look in the libgloss linker scripts you will see a bunch of uses
> of NOLOAD.
>
> I'm not sure whether any of them are really necessary, but they are
> certainly there.
>
> Ian
>

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/12771] internal error in value_from_output_section, at ../../gold/reloc.cc:1508 on armel

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12771

--- Comment #13 from Doug Kwan  2011-07-06 07:00:26 
UTC ---
(In reply to comment #12)
> There is no doubt that the patch is incomplete.  That just fixed a single
> instance of code that must be fixed in a number of different places.

I have a patch for doing unaligned accesses for all static data relocations.  I
will post it when it is ready.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/12771] internal error in value_from_output_section, at ../../gold/reloc.cc:1508 on armel

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12771

--- Comment #14 from Doug Kwan  2011-07-06 07:48:56 
UTC ---
(In reply to comment #13)
> (In reply to comment #12)
> > There is no doubt that the patch is incomplete.  That just fixed a single
> > instance of code that must be fixed in a number of different places.
> 
> I have a patch for doing unaligned accesses for all static data relocations.  
> I
> will post it when it is ready.

Done.  Please see the patch in:

http://sourceware.org/ml/binutils/2011-07/msg00075.html

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/11264] linker warning "sh_link not set for section `.ARM.exidx'" when using shared library linked by gold

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11264

Doug Kwan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dougkwan at google dot com
 Resolution||FIXED

--- Comment #1 from Doug Kwan  2011-07-06 18:25:39 
UTC ---
This should be fixed in trunk by this patch in April.

2011-04-22  Doug Kwan  

* arm.cc (Arm_output_section::Arm_output_section): Set SHF_LINK_ORDER
flag of a SHT_ARM_EXIDX section.
* testsuite/Makefile.am (arm_exidx_test): New test rules.
* testsuite/Makefile.in: Regenerate.
* testsuite/arm_exidx_test.s: New file.
* testsuite/arm_exidx_test.sh: Same.

2.21 is still broken.  This probably is not a big issue.  The problem was that
gold incorrectly missed setting SHF_LINK_ORDER in .ARM.exidx section headers. 
I am not aware of any use of that flag in unwinding.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/12771] internal error in value_from_output_section, at ../../gold/reloc.cc:1508 on armel

[dougkwan at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12771

Doug Kwan  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #17 from Doug Kwan  2011-07-06 18:20:05 
UTC ---
I checked a fix in the trunk.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils