[Bug gas/15649] ARM - Invalid constant after fixup with shifted immediate values

2013-06-20 Thread m.lesniewski at samsung dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15649



Michał Leśniewski  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

2013-06-20 Thread Tristan Gingold

On Jun 19, 2013, at 11:31 AM, Merijn van de Klundert  
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

2013-06-20 Thread caojinyu at msn dot com
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

2013-06-20 Thread caojinyu at msn dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15657

wawa  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

2013-06-20 Thread mxcl at me dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=11337

Max Howell  changed:

   What|Removed |Added

 CC||mxcl at me dot com

--- Comment #8 from Max Howell  ---
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 binutils/11337] windres compiles menus and dialogs to UNICODE not ANSI

2013-06-20 Thread mxcl at me dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=11337



--- Comment #9 from Max Howell  ---

For others who may come here, a better solution would be to use MingW64.

MingW32—dare I saw—is a little unmaintained nowadays.



-- 

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

2013-06-20 Thread marxin.liska at gmail dot com
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
obj/ui/compositor/libcompositor

[Bug gold/15660] out of file descriptors and couldn't close any

2013-06-20 Thread ian at airs dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15660

--- Comment #1 from Ian Lance Taylor  ---
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

2013-06-20 Thread ccoutant at google dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15660

--- Comment #2 from Cary Coutant  ---
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

2013-06-20 Thread marxin.liska at gmail dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15660



--- Comment #3 from Martin Liška  ---

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

2013-06-20 Thread ccoutant at google dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15660

--- Comment #4 from Cary Coutant  ---
> 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

2013-06-20 Thread marxin.liska at gmail dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15660



--- Comment #5 from Martin Liška  ---

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

2013-06-20 Thread ccoutant at google dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15660

--- Comment #6 from Cary Coutant  ---
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
 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/supp

[Bug gold/15660] out of file descriptors and couldn't close any

2013-06-20 Thread marxin.liska at gmail dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15660



--- Comment #7 from Martin Liška  ---

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

2013-06-20 Thread terry.guo at arm dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15302

Terry Guo  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2013-06-21
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #7 from Terry Guo  ---
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