[Bug gas/15649] ARM - Invalid constant after fixup with shifted immediate values
http://sourceware.org/bugzilla/show_bug.cgi?id=15649 Michał Leśniewski m.lesniewski at samsung dot com changed: What|Removed |Added CC||m.lesniewski at samsung do t 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
Re: question on gnu ld on mac
On Jun 19, 2013, at 11:31 AM, Merijn van de Klundert merijn...@hotmail.com wrote: Dear member or developer of binutils, I've tried to install gnu ld on my macbook (I need this to compile a certain makefile, which containts options that are not recognized by the linker of snow leopard. This makefile runs smooth on a linux distribution with GNU ld). basically, everything in binutils compiles (i.e. configure, make and make install work without error). For example running these in the top directory works and do so as well in for example the gas or gold directory. I can run configure and make flawless in the ld directory, however make install gives an error: install: ldscripts/*: No such file or directory I tried to make a softlink to this directory (which is empty) and it doesn't help. However, in ld/bin is now a file called ld When I try to use this as linker I get the error message: /Users/merijnvandeklundert/PhD/Castor/Linker/binutils-2.23.2/ld/bin/ld: unrecognised emulation mode: Supported emulations: So it seemed to have failed still. (also I tried running make all-ld from the top directory, which runs but doesn't seem to create an executable). I looked into installing it via macports, but some macports webpage seems to indicate that gnu ld simply won't run on mac: http://trac.macports.org/ticket/24471 Is this true or am I doing something wrong? That's correct. GNU ld hasn't been ported to target darwin. Tristan. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/15657] New: in the function _bfd_stringtab_add, which is in binutils-2.23/bfd/hash.c
http://sourceware.org/bugzilla/show_bug.cgi?id=15657
Bug ID: 15657
Summary: in the function _bfd_stringtab_add, which is in
binutils-2.23/bfd/hash.c
Product: binutils
Version: 2.23
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: caojinyu at msn dot com
the function _bfd_stringtab_add,
if (! copy)
entry-root.string = str;
else
{
char *n;
n = (char *) bfd_hash_allocate (tab-table, strlen (str) + 1);
if (n == NULL)
return (bfd_size_type) -1;
entry-root.string = n;
}
I think it should like this:
if (! copy)
entry-root.string = str;
else
{
char *n;
n = (char *) bfd_hash_allocate (tab-table, strlen (str) + 1);
if (n == NULL)
return (bfd_size_type) -1;
memcpy(n, str, strlen(str)+1);
entry-root.string = n;
}
Because if copy is true, then we should copy the str in the n, which was
allocate by bfd_hash_allocate.
--
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 binutils/15657] in the function _bfd_stringtab_add, which is in binutils-2.23/bfd/hash.c
http://sourceware.org/bugzilla/show_bug.cgi?id=15657 wawa caojinyu at msn dot com changed: What|Removed |Added CC||caojinyu at msn 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 binutils/11337] windres compiles menus and dialogs to UNICODE not ANSI
http://sourceware.org/bugzilla/show_bug.cgi?id=11337 Max Howell mxcl at me dot com changed: What|Removed |Added CC||mxcl at me dot com --- Comment #8 from Max Howell mxcl at me dot com --- Confirmed this bug still occurs with `GNU windres (GNU Binutils) 2.23.2` on OS X 10.8. Bug is now three years old, happy to help fix it if someone would give me a pointer. I fixed it by adding L in front of all my strings in the RC, however I am loath to do this because it means when compiling from Windows MingW it won't work or will require additional flags (don't know which yet). -- 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/15660] New: out of file descriptors and couldn't close any
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 Bug ID: 15660 Summary: out of file descriptors and couldn't close any Product: binutils Version: 2.23 Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ian at airs dot com Reporter: marxin.liska at gmail dot com CC: ccoutant at google dot com I've encountered similar bug to: http://sourceware.org/bugzilla/show_bug.cgi?id=10708 during linking of chromium binary. ld --version GNU gold (GNU Binutils 2.23.52.20130526) 1.11 Command line: FAILED: flock linker.lock g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -pie -L. -flto=9 -fno-fat-lto-objects -O2 --param lto-partitions=64 -o chrome -Wl,--start-group obj/chrome/app/chrome.chrome_exe_main_gtk.o obj/chrome/app/chrome.chrome_main.o obj/chrome/app/chrome.chrome_main_delegate.o obj/chrome/libinstaller_util.a obj/media/libmedia_sse.a obj/third_party/icu/libicuuc.a obj/third_party/libjingle/libjingle.a obj/skia/libskia_opts.a obj/third_party/icu/libicudata.a obj/device/libdevice_media_transfer_protocol.a obj/native_client/src/trusted/service_runtime/arch/x86/libservice_runtime_x86_common.a obj/chrome/libservice.a obj/chrome/librenderer.a obj/webkit/support/libglue.a obj/content/libcontent_worker.a obj/third_party/libwebp/libwebp_utils.a obj/third_party/zlib/libminizip.a obj/chrome/browser/performance_monitor/libperformance_monitor.a obj/third_party/leveldatabase/libleveldatabase.a obj/native_client/src/trusted/service_runtime/libenv_cleanser.a obj/sandbox/libc_urandom_override.a obj/chrome/libbrowser.a obj/ppapi/libppapi_host.a obj/sync/libsync_core.a obj/gpu/libgles2_cmd_helper.a obj/third_party/smhasher/libcityhash.a obj/third_party/libphonenumber/libphonenumber.a obj/chrome/app/policy/libpolicy.a obj/webkit/support/libplugins_common.a obj/native_client/src/trusted/validator_x86/libnccopy_x86_64.a obj/webkit/support/libglue_common.a obj/webkit/renderer/compositor_bindings/libwebkit_compositor_support.a obj/third_party/smhasher/libmurmurhash3.a obj/content/libcontent_gpu.a obj/native_client/src/trusted/threading/libthread_interface.a obj/media/libmedia_mmx.a obj/ipc/libipc.a obj/third_party/libxslt/libxslt.a obj/remoting/libremoting_client.a obj/third_party/ots/libots.a obj/base/libsymbolize.a obj/native_client/src/trusted/validator/libvalidators.a obj/chrome/libbrowser_extensions.a obj/skia/libskia_opts_ssse3.a obj/third_party/protobuf/libprotobuf_lite.a obj/third_party/WebKit/Source/core/core.gyp/libwebcore_platform.a obj/ui/surface/libsurface.a obj/third_party/WebKit/Source/WebKit/chromium/libwebkit.a obj/native_client/src/trusted/validator/x86/64/libncvalidate_x86_64.a obj/third_party/jsoncpp/libjsoncpp.a obj/google_apis/libgoogle_apis.a obj/chrome/libnacl.a obj/third_party/libphonenumber/libphonenumber_without_metadata.a obj/chrome/libdebugger.a obj/v8/tools/gyp/libv8_snapshot.a obj/ui/native_theme/libnative_theme.a obj/third_party/libusb/libusb.a obj/content/libcontent_common_child.a obj/native_client/src/trusted/nacl_base/libnacl_base.a obj/base/libbase_static.a obj/native_client/src/shared/imc/libimc.a obj/chrome/libfeedback_proto.a obj/components/libbrowser_context_keyed_service.a obj/components/libweb_modal.a obj/chrome/libapps.a obj/third_party/WebKit/Source/core/core.gyp/libwebcore_platform_geometry.a obj/components/libuser_prefs.a obj/content/libcontent_utility.a obj/third_party/libevent/libevent.a obj/sandbox/libseccomp_bpf.a obj/build/linux/libpci.a obj/ui/gl/libgl_wrapper.a obj/third_party/mt19937ar/libmt19937ar.a obj/third_party/angle/src/libtranslator_common.a obj/ui/message_center/libmessage_center.a obj/third_party/libpng/libpng.a obj/components/libwebdata_common.a obj/third_party/opus/libopus.a obj/sync/libsync_notifier.a obj/ui/snapshot/libsnapshot.a obj/native_client/src/trusted/validator/x86/libncval_base_x86_64.a obj/webkit/support/libwebkit_media.a obj/third_party/libwebp/libwebp_dsp.a obj/third_party/harfbuzz-ng/libharfbuzz-ng.a obj/chrome/app/policy/libcloud_policy_proto_generated_compile.a obj/base/allocator/liballocator_extension_thunks.a obj/remoting/libremoting_jingle_glue.a obj/native_client/src/trusted/service_runtime/libnacl_error_code.a obj/third_party/snappy/libsnappy.a obj/cc/libcc.a obj/third_party/libjingle/libjingle_p2p_constants.a obj/third_party/cld/libcld.a obj/third_party/libxml/libxml2.a obj/webkit/support/libplugins.a obj/chrome/libvariations_seed_proto.a obj/remoting/proto/libchromotocol_proto_lib.a obj/native_client/src/trusted/simple_service/libsimple_service.a obj/chrome/libsync_file_system_proto.a obj/gpu/libdisk_cache_proto.a obj/third_party/WebKit/Source/core/core.gyp/libwebcore_html.a obj/native_client/src/trusted/interval_multiset/libnacl_interval.a obj/build/linux/libspeechd.a obj/sync/libsync_internal_api.a obj/third_party/hunspell/libhunspell.a obj/chrome/libplugin.a
[Bug gold/15660] out of file descriptors and couldn't close any
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #1 from Ian Lance Taylor ian at airs dot com --- What does ulimit -n display? -- 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/15660] out of file descriptors and couldn't close any
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #2 from Cary Coutant ccoutant at google dot com --- Is there any way that you can shrink the extent of the --start-group/--end-group options? My first guess is that it's related to having all those files inside the library group. In particular, .o files do not need to be inside the group. It might be better to build a thin archive from all those .a files, then just link against the thin archive (the linker will treat all the nested member libraries as one giant archive library). -- 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/15660] out of file descriptors and couldn't close any
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #3 from Martin Liška marxin.liska at gmail dot com --- ulimit -n 1024 I tried same command line without --start-group/--end-group, but didn't hel p. Next step was to create one large archive, so: ar r [list of all *.a] /tmp/lib.a g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -pie -L. -flt o=9 -fno-fat-lto-objects -O2 --param lto-partitions=64 -o chrome obj/chrome/app/chrome.chrome_exe_main_gtk.o obj/chrome/app/chrome.chrome_ma in.o obj/chrome/app/chrome.chrome_main_delegate.o /tmp/lib.a -lX11 -lXcursor -lXrandr -lXrender -lXss -lXext -lrt -ldl -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lXtst -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio -2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfree type -lfontconfig -lXi -lsmime3 -lnssutil3 -lnss3 -lplds4 -lplc4 -lnspr4 -lgconf -2 -lresolv -lXcomposite -lasound -lXdamage -lXfixes -lcups -lgnutls -lgcrypt -lgpg-error -lz -lpthread -lcrypt -lm -L/usr/lib64 -lexpat -ldbus-1 -ludev I was shown big amount of undefined symbols, did I use the correct way how to create the archive? Thanks, Martin -- 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/15660] out of file descriptors and couldn't close any
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #4 from Cary Coutant ccoutant at google dot com --- Next step was to create one large archive, so: ar r [list of all *.a] /tmp/lib.a g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -pie -L. -flto=9 -fno-fat-lto-objects -O2 --param lto-partitions=64 -o chrome obj/chrome/app/chrome.chrome_exe_main_gtk.o obj/chrome/app/chrome.chrome_main.o obj/chrome/app/chrome.chrome_main_delegate.o /tmp/lib.a -lX11 -lXcursor -lXrandr -lXrender -lXss -lXext -lrt -ldl -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lXtst -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lXi -lsmime3 -lnssutil3 -lnss3 -lplds4 -lplc4 -lnspr4 -lgconf-2 -lresolv -lXcomposite -lasound -lXdamage -lXfixes -lcups -lgnutls -lgcrypt -lgpg-error -lz -lpthread -lcrypt -lm -L/usr/lib64 -lexpat -ldbus-1 -ludev I was shown big amount of undefined symbols, did I use the correct way how to create the archive? You need the 'T' option to make a thin archive. Otherwise an archive of other archives makes a plain non-library archive file. -cary -- 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/15660] out of file descriptors and couldn't close any
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #5 from Martin Liška marxin.liska at gmail dot com --- I did so, thin library was created, but linker is still complaining about f ile descriptors: g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -pie -L. -flt o=9 -fno-fat-lto-objects -O2 --param lto-partitions=64 -o chrome obj/chrome/app/chrome.chrome_exe_main_gtk.o obj/chrome/app/chrome.chrome_ma in.o obj/chrome/app/chrome.chrome_main_delegate.o lib.a -lX11 -lXcursor -lXrandr -lXrender -lXss -lXext -lrt -ldl -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lXtst -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfree type -lfontconfig -lXi -lsmime3 -lnssutil3 -lnss3 -lplds4 -lplc4 -lnspr4 -lgconf -2 -lresolv -lXcomposite -lasound -lXdamage -lXfixes -lcups -lgnutls -lgcrypt -lgpg-error -lz -lpthread -lcrypt -lm -L/usr/lib64 -lexpat -ldbus-1 -ludev -- 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/15660] out of file descriptors and couldn't close any
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #6 from Cary Coutant ccoutant at google dot com --- Does the problem only happen with -flto? I wonder if the plugin is keeping files open. Can you tar up the build directory so I can try to repro the problem? -cary On Thu, Jun 20, 2013 at 1:43 PM, marxin.liska at gmail dot com sourceware-bugzi...@sourceware.org wrote: http://sourceware.org/bugzilla/show_bug.cgi?id=15660 Bug ID: 15660 Summary: out of file descriptors and couldn't close any Product: binutils Version: 2.23 Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ian at airs dot com Reporter: marxin.liska at gmail dot com CC: ccoutant at google dot com I've encountered similar bug to: http://sourceware.org/bugzilla/show_bug.cgi?id=10708 during linking of chromium binary. ld --version GNU gold (GNU Binutils 2.23.52.20130526) 1.11 Command line: FAILED: flock linker.lock g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -pie -L. -flto=9 -fno-fat-lto-objects -O2 --param lto-partitions=64 -o chrome -Wl,--start-group obj/chrome/app/chrome.chrome_exe_main_gtk.o obj/chrome/app/chrome.chrome_main.o obj/chrome/app/chrome.chrome_main_delegate.o obj/chrome/libinstaller_util.a obj/media/libmedia_sse.a obj/third_party/icu/libicuuc.a obj/third_party/libjingle/libjingle.a obj/skia/libskia_opts.a obj/third_party/icu/libicudata.a obj/device/libdevice_media_transfer_protocol.a obj/native_client/src/trusted/service_runtime/arch/x86/libservice_runtime_x86_common.a obj/chrome/libservice.a obj/chrome/librenderer.a obj/webkit/support/libglue.a obj/content/libcontent_worker.a obj/third_party/libwebp/libwebp_utils.a obj/third_party/zlib/libminizip.a obj/chrome/browser/performance_monitor/libperformance_monitor.a obj/third_party/leveldatabase/libleveldatabase.a obj/native_client/src/trusted/service_runtime/libenv_cleanser.a obj/sandbox/libc_urandom_override.a obj/chrome/libbrowser.a obj/ppapi/libppapi_host.a obj/sync/libsync_core.a obj/gpu/libgles2_cmd_helper.a obj/third_party/smhasher/libcityhash.a obj/third_party/libphonenumber/libphonenumber.a obj/chrome/app/policy/libpolicy.a obj/webkit/support/libplugins_common.a obj/native_client/src/trusted/validator_x86/libnccopy_x86_64.a obj/webkit/support/libglue_common.a obj/webkit/renderer/compositor_bindings/libwebkit_compositor_support.a obj/third_party/smhasher/libmurmurhash3.a obj/content/libcontent_gpu.a obj/native_client/src/trusted/threading/libthread_interface.a obj/media/libmedia_mmx.a obj/ipc/libipc.a obj/third_party/libxslt/libxslt.a obj/remoting/libremoting_client.a obj/third_party/ots/libots.a obj/base/libsymbolize.a obj/native_client/src/trusted/validator/libvalidators.a obj/chrome/libbrowser_extensions.a obj/skia/libskia_opts_ssse3.a obj/third_party/protobuf/libprotobuf_lite.a obj/third_party/WebKit/Source/core/core.gyp/libwebcore_platform.a obj/ui/surface/libsurface.a obj/third_party/WebKit/Source/WebKit/chromium/libwebkit.a obj/native_client/src/trusted/validator/x86/64/libncvalidate_x86_64.a obj/third_party/jsoncpp/libjsoncpp.a obj/google_apis/libgoogle_apis.a obj/chrome/libnacl.a obj/third_party/libphonenumber/libphonenumber_without_metadata.a obj/chrome/libdebugger.a obj/v8/tools/gyp/libv8_snapshot.a obj/ui/native_theme/libnative_theme.a obj/third_party/libusb/libusb.a obj/content/libcontent_common_child.a obj/native_client/src/trusted/nacl_base/libnacl_base.a obj/base/libbase_static.a obj/native_client/src/shared/imc/libimc.a obj/chrome/libfeedback_proto.a obj/components/libbrowser_context_keyed_service.a obj/components/libweb_modal.a obj/chrome/libapps.a obj/third_party/WebKit/Source/core/core.gyp/libwebcore_platform_geometry.a obj/components/libuser_prefs.a obj/content/libcontent_utility.a obj/third_party/libevent/libevent.a obj/sandbox/libseccomp_bpf.a obj/build/linux/libpci.a obj/ui/gl/libgl_wrapper.a obj/third_party/mt19937ar/libmt19937ar.a obj/third_party/angle/src/libtranslator_common.a obj/ui/message_center/libmessage_center.a obj/third_party/libpng/libpng.a obj/components/libwebdata_common.a obj/third_party/opus/libopus.a obj/sync/libsync_notifier.a obj/ui/snapshot/libsnapshot.a obj/native_client/src/trusted/validator/x86/libncval_base_x86_64.a obj/webkit/support/libwebkit_media.a obj/third_party/libwebp/libwebp_dsp.a obj/third_party/harfbuzz-ng/libharfbuzz-ng.a obj/chrome/app/policy/libcloud_policy_proto_generated_compile.a obj/base/allocator/liballocator_extension_thunks.a obj/remoting/libremoting_jingle_glue.a obj/native_client/src/trusted/service_runtime/libnacl_error_code.a obj/third_party/snappy/libsnappy.a obj/cc/libcc.a obj/third_party/libjingle/libjingle_p2p_constants.a obj/third_party/cld/libcld.a obj/third_party/libxml/libxml2.a obj/webkit/support/libplugins.a
[Bug gold/15660] out of file descriptors and couldn't close any
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #7 from Martin Liška marxin.liska at gmail dot com --- I'll try to link it without -flto, but I used -fno-fat-lto-objects. It will take me some time to recompile chromium. Weird is that ld.bfd is able to link the binary with -flto (aside gcc relat ed errors). -- 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/15302] Branching to linker script symbol is resolved to improperly BLX instruction for cortex-m3
http://sourceware.org/bugzilla/show_bug.cgi?id=15302
Terry Guo terry.guo at arm dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed||2013-06-21
Resolution|FIXED |---
Ever confirmed|0 |1
--- Comment #7 from Terry Guo terry.guo at arm dot com ---
I am sorry that I have to reopen it. The proposed patch will cause below issue.
In the below concrete case, the __init_array_start is allocated at address
0x11a40 actually. But any relocations using address of __init_array_start will
be resolved to use address 0x11a41 by linker, thus the subsequential deference
on __init_array_start is a deference on wrong address (0x11a41).
This is because the proposed patch set ST_BRANCH_TO_THUMB to the symbol
__init_array_start, then the last bit of its address is set by the linker
function elf32_arm_swap_symbol_out.
To reproduce this issue, an ARM baremetal toolchain using Newlib as C library
is needed. Then use below command to build a project with empty main function:
arm-none-eabi-gcc -mthumb -mcpu=cortex-m3 -O2 -lc -lrdimon -specs=rdimon.specs
test.c -o test.out -Wl,-verbose -Wl,-Map=test.map
Then run test.out on QEMU, a Segmentation falut will be reported.
qemu-system-arm -cpu cortex-m3 -nographic -monitor null -serial null
-semihosting -kernel ./test.out
This QEMU segmentation fault is caused by deference of __init_array_start in
function __libc_init_array.
Here are some investigations:
Disassemble the test.out with command arm-none-eabi-objdump -D test.out and
we will see:
Disassembly of section .init_array:
00011a40 __init_array_start:
11a40: 802dandeq r8, r0, sp, lsr #32
The __init_array_start is allocated at address 0x11a40 actually.
Meanwhile the command arm-none-eabi-readelf -s test.out, we will get symbol
table:
222: 00011a41 0 FUNCLOCAL DEFAULT7 __init_array_start
Thus any instructions using __init_array_start will be resolved to 0x11a41
instead of 0x11a40.
movwr5, #:lower16:__init_array_start
movtr5, #:upper16:__init_array_start
ldr r3, [r5, #4]!
blx r3
in the above case, the r5 will get wrong value 0x11a41, then r3 will get wrong
value, finally the blx will cause the fault.
Here are some background on Newlib:
In Newlib init.c we have code:
extern void (*__init_array_start []) (void) __attribute__((weak));
extern void (*__init_array_end []) (void) __attribute__((weak));
void
__libc_init_array (void)
{
size_t count;
size_t i;
count = __init_array_end - __init_array_start;
for (i = 0; i count; i++)
__init_array_start[i] ();
}
Both __init_array_start and __init_array_end are defined in linker script as:
.init_array :
{
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array ))
PROVIDE_HIDDEN (__init_array_end = .);
}
--
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
