http://permalink.gmane.org/gmane.comp.gnu.binutils hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.gnu.binutils/57730 <pre> Thanks, this is a much better fix. When I marked define_special_symbol to be always inline to test, it failed in another place so the previous patch would have not fully addressed the problem. Committed this patch: Index: ChangeLog =================================================================== RCS file: /cvs/src/src/gold/ChangeLog,v retrieving revision 1.917 diff -u -u -p -r1.917 ChangeLog --- ChangeLog24 May 2012 01:02:14 -00001.917 +++ ChangeLog25 May 2012 22:53:09 -0000 &lt; at &gt;&lt; at &gt; -1,3 +1,8 &lt; at &gt;&lt; at &gt; +2012-05-25 Sriraman Tallam &lt;tmsriram&lt; at &gt;google.com&gt; + +* symtab.cc (Symbol_table::define_special_symbol): +Initialize *poldsym to prevent uninitialized variable errors. + 2012-05-23 Cary Coutant &lt;ccoutant&lt; at &gt;google.com&gt; * layout.cc (Layout::section_name_mapping): Add rules to handle Index: symtab.cc =================================================================== RCS file: /cvs/src/src/gold/symtab.cc,v retrieving revision 1.165 diff -u -u -p -r1.165 symtab.cc --- symtab.cc22 May 2012 23:50:52 -00001.165</pre> Sriraman Tallam 2012-05-25T22:56:47 http://permalink.gmane.org/gmane.comp.gnu.binutils/57729 <pre> Instead of this, change Symbol_table::define_special_symbol to set *poldsym = NULL at the top of the function. That patch is approved if it fixes the problem. Ian </pre> Ian Lance Taylor 2012-05-25T22:36:38 http://permalink.gmane.org/gmane.comp.gnu.binutils/57728 <pre>Hi, Patch ok? This was causing an uninitialized variable error while building. * symtab.cc (Symbol_table::add_undefined_symbol_from_command_line): Initialize oldsym to prevent uninitialized variable errors. Index: symtab.cc =================================================================== RCS file: /cvs/src/src/gold/symtab.cc,v retrieving revision 1.165 diff -u -u -p -r1.165 symtab.cc --- symtab.cc22 May 2012 23:50:52 -00001.165 +++ symtab.cc25 May 2012 21:40:38 -0000 &lt; at &gt;&lt; at &gt; -2345,7 +2345,7 &lt; at &gt;&lt; at &gt; Symbol_table::add_undefined_symbol_from_ const char* version = NULL; Sized_symbol&lt;size&gt;* sym; - Sized_symbol&lt;size&gt;* oldsym; + Sized_symbol&lt;size&gt;* oldsym = NULL; bool resolve_oldsym; if (parameters-&gt;target().is_big_endian()) { Thanks, -Sri. </pre> Sriraman Tallam 2012-05-25T21:42:56 http://permalink.gmane.org/gmane.comp.gnu.binutils/57727 <pre>Hi, I checked in this patch not to use ynamic_sec_flags to create PLT .eh_frame section. H.J. --- diff --git a/bfd/ChangeLog b/bfd/ChangeLog index 2165cd8..9834aab 100644 --- a/bfd/ChangeLog +++ b/bfd/ChangeLog &lt; at &gt;&lt; at &gt; -1,3 +1,9 &lt; at &gt;&lt; at &gt; +2012-05-25 H.J. Lu &lt;hongjiu.lu&lt; at &gt;intel.com&gt; + +* elf32-i386.c (elf_i386_create_dynamic_sections): Don't use +dynamic_sec_flags to create PLT .eh_frame section. +* elf64-x86-64.c (elf_x86_64_create_dynamic_sections): Likewise. + 2012-05-25 Alan Modra &lt;amodra&lt; at &gt;gmail.com&gt; PR ld/13909 diff --git a/bfd/elf32-i386.c b/bfd/elf32-i386.c index 7b33d77..6aa386d 100644 --- a/bfd/elf32-i386.c +++ b/bfd/elf32-i386.c &lt; at &gt;&lt; at &gt; -1018,12 +1018,11 &lt; at &gt;&lt; at &gt; elf_i386_create_dynamic_sections (bfd *dynobj, struct bfd_link_info *info) &amp;&amp; htab-&gt;plt_eh_frame == NULL &amp;&amp; htab-&gt;elf.splt != NULL) { - flagword flags = get_elf_backend_data (dynobj)-&gt;dynamic_sec_flags; + flagword flags = (SEC_ALLOC | SEC_LOAD | SEC_READONLY +| SEC_HAS_CONTENTS | SEC_IN_MEMORY +| SEC_LINKER_CREATED);</pre> H.J. Lu 2012-05-25T16:20:57 http://permalink.gmane.org/gmane.comp.gnu.binutils/57726 <pre> Multibyte symbol names generated by GCC (with -fextended-identifiers and \u or \U UCNs in identifiers) do always use UTF-8 in the .s file. GCC translates to the locale encoding as needed for diagnostics. </pre> Joseph S. Myers 2012-05-25T14:34:01 http://permalink.gmane.org/gmane.comp.gnu.binutils/57725 <pre> Nick&gt; Does anyone have any objections or questions concerning adding such a Nick&gt; feature ? Not an objection, but I think a world where symbols use the locale's encoding is subject to all kinds of truly crazy scenarios. Maybe we're in that world already, I don't really know. gdb studiously avoids the issue. If we're not in that world, then let's please not enter it. If we're already there, maybe at least for GNU systems we can switch out of it and make it all use UTF-8... ? Tom </pre> Tom Tromey 2012-05-25T14:19:55 http://permalink.gmane.org/gmane.comp.gnu.binutils/57724 <pre>Currently, bfd_fopen has confused error handling. If the caller passes in a file descriptor, then on any error exit before fdopen is called, the fd will be left open; but on any error exit after fdopen is called, the fd will be closed. This patch changes bfd_fopen to always close the fd on error. I audited all callers of bfd_fopen and bfd_fdopen in gdb, binutils, and ld and fixed them not to close the fd on error. There was only one call outside of gdb, in ar.c, and it immediately calls bfd_fatal, and so does not need a change. Ok? Tom b/bfd/ChangeLog: 2012-05-25 Tom Tromey &lt;tromey&lt; at &gt;redhat.com&gt; * opncls.c (bfd_fopen): Always close fd on failure. (bfd_fdopenr): Likewise. b/gdb/ChangeLog: 2012-05-25 Tom Tromey &lt;tromey&lt; at &gt;redhat.com&gt; * symfile.c (symfile_bfd_open): Don't close desc if bfd_fopen fails. * solib.c (solib_bfd_fopen): Don't close fd if bfd_fopen fails. * exec.c (exec_file_attach): Don't close scratch_chan if bfd_fopen fails. * dwarf2read.c (try_open_dwo_file): Don't close fd if bfd</pre> Tom Tromey 2012-05-25T13:52:11 http://permalink.gmane.org/gmane.comp.gnu.binutils/57723 <pre>Hi mpsuzuki, There are no stupid questions, only stupid answers. :-) I agree, this is probably a common case. The patched code does include a check to see if the multibyte string can be displayed in the current execution environment. If it cannot then the code falls back on the old behaviour of displaying the multibyte characters as a sequence of hexadecimal bytes. Evaluated: yes. Been able to do anything about it: no. It is really up to the system administrator where the tools are being used to make sure that they were compiled with the correct character set settings, and that these settings are then used when the tools are used. Cheers Nick </pre> nick clifton 2012-05-25T08:38:25 http://permalink.gmane.org/gmane.comp.gnu.binutils/57722 <pre>Hi Hans-Peter, Indeed a good point. It turns out that writing a test case is a lot harder than writing the code to display the multibyte characters. Not least because currently we have no way of generating multibyte symbol names. (I developed the patch using a binary given to me under NDA by a customer, so I cannot use that binary in the testsuite). I am currently working on a way to generate multibyte symbol names and then using this to create a testcase. Hmm, yes. This is getting tricky... This much I did test, and the are no regressions from the patch. Cheers Nick </pre> nick clifton 2012-05-25T08:24:44 http://permalink.gmane.org/gmane.comp.gnu.binutils/57721 <pre> As projects are growing in code size more and more are being affected by this bug we are also requiring a lot of use of --no-relax in the Debian Alpha port. That gcc is now being affected by it is a real problem. I am prepared to assist in testing including running debugging versions of binutils under gdb to see if we can better isolate the problem and find a solution, but I would need guidance since I know very little of the binutils code. Cheers Michael. </pre> Michael Cree 2012-05-25T02:20:15 http://permalink.gmane.org/gmane.comp.gnu.binutils/57720 <pre>Hi Richard, I began testing gcc-4.7.0 today on alpha and remembered that &gt;=gcc-4.6 cannot build itself on alpha without passing -Wl,--no-relax. See http://sources.redhat.com/bugzilla/show_bug.cgi?id=5276 We (Gentoo) have work-arounds in place for a number of large projects. Can you offer any insight or assistance? Thanks, Matt </pre> Matt Turner 2012-05-25T02:07:50 http://permalink.gmane.org/gmane.comp.gnu.binutils/57719 <pre> This change seems fine to me. The failing case that led us write that test originally had instructions in it anyway, but we wanted to genericize and simplify it. Strange that xtensa is the only target to run it, but OK then. Sterling </pre> Sterling Augustine 2012-05-24T15:54:57 http://permalink.gmane.org/gmane.comp.gnu.binutils/57718 <pre>gas/lns/lns-big-delta has been failing on xtensa (the only target to run this test) since Richard's 2011-09-05 change to gas/dwarf2dbg.c. I reckon the test itself is somewhat suspect, since .loc specifies line number info for instructions, and the test has no instructions (unless you count .space as an instruction). So, let's fix the test. I'm not hugely concerned, but the old test does illustrate some problems with queuing line info: We don't emit queued line info if .loc is not followed by an insn or label (no line info at all for the old test), and perhaps the queue should be flushed on pseudos like .space that bump pc? gcc asm can do all sorts of weird tricks. eg. int foo (void) { __asm__ (".p2align 8"); return 0; } results in .loc 1 3 0 #APP # 3 "/src/tmp/asmloc.c" 1 .p2align 8 # 0 "" 2 .loc 1 4 0 #NO_APP movl $0, %eax so with queuing, the ".p2align" loses its line number info to the "movl". Thoughts? * gas/lns/lns-big-delta.s: Add nops. * gas/lns/lns-</pre> Alan Modra 2012-05-24T15:35:42 http://permalink.gmane.org/gmane.comp.gnu.binutils/57717 <pre> Works for me. Thanks. </pre> H.J. Lu 2012-05-24T15:29:47 http://permalink.gmane.org/gmane.comp.gnu.binutils/57716 <pre> Would someone commit, please? I have to write access to binutils. </pre> Georg-Johann Lay 2012-05-24T10:57:36 http://permalink.gmane.org/gmane.comp.gnu.binutils/57715 <pre> Hello, I have seen that you have run coremark on RL78 G13, Should it be possible to know the coremark score you get on this platform? Thank you a lot, Best regards Antoine </pre> antoine odonne 2012-05-24T10:36:41 http://permalink.gmane.org/gmane.comp.gnu.binutils/57714 <pre> HJ, how does this look to you? Moving _bfd_elf_maybe_strip_eh_frame_hdr later in bfd_elf_size_dynamic_sections allows us to treat the linker created PLT .eh_frame section like most other linker created sections. We don't need to set it up as early, nor do we rely on elf-eh-frame.c stripping the section by cunningly leaving an FDE range as zero. bfd/ * elf-eh-frame.c (_bfd_elf_eh_frame_present): New function. (_bfd_elf_maybe_strip_eh_frame_hdr): Use it here. * elf-bfd.h (_bfd_elf_eh_frame_present): Declare. * elflink.c (bfd_elf_size_dynamic_sections): Let the backend size dynamic sections before stripping eh_frame_hdr. (bfd_elf_gc_sections): Handle multiple .eh_frame sections. * elf32-ppc.c (ppc_elf_size_dynamic_sections): Drop glink_eh_frame if no other .eh_frame sections exist. * elf64-ppc.c (ppc64_elf_size_stubs): Likewise. * elf32-i386.c (elf_i386_create_dynamic_sections): Don't size or alloc plt_eh_frame here.. (elf_i386_size_dynamic_sections): ..do it here instead. Don't specially keep </pre> Alan Modra 2012-05-24T08:22:52 http://permalink.gmane.org/gmane.comp.gnu.binutils/57713 <pre>2012/5/23 Georg-Johann Lay &lt;avr&lt; at &gt;gjlay.de&gt;: Approved. Denis. </pre> Denis Chertykov 2012-05-24T07:23:57 http://permalink.gmane.org/gmane.comp.gnu.binutils/57712 <pre>PowerPC64 linker generated .eh_frame for PLT call stubs uses DW_EH_PE_pcrel | DW_EH_PE_sdata4 encoding for addresses, and thus aligns .eh_frame to 4 bytes. Current gcc uses the same encoding, but probably because gcc hasn't changed its .eh_frame alignment from the days it generated 8-byte addresses, aligns to 8 bytes. This means ld will insert padding between the linker generated .eh_frame and user .eh_frame sections. The padding is seen as a terminator, which breaks exception handling for anyone not reading the FDEs via .eh_frame_hdr. The common case of course is to call ld with --eh-frame-hdr, which is why I hadn't seen this problem until now. PR ld/14158 * elf64-ppc.c (ppc64_elf_size_stubs): Round up glink_eh_frame size to output section alignment. (ppc64_elf_build_stubs): Likewise, and extend last FDE to cover. Index: bfd/elf64-ppc.c =================================================================== RCS file: /cvs/src/src/bfd/elf64-ppc.c,v retrieving revision 1.383 diff -u -p -r1.383 elf64-ppc.</pre> Alan Modra 2012-05-24T06:20:12 http://permalink.gmane.org/gmane.comp.gnu.binutils/57711 <pre> Fine with me! -cary </pre> Cary Coutant 2012-05-24T01:05:16 http://permalink.gmane.org/gmane.comp.gnu.binutils/57710 <pre>Excuse me, please let me ask a stupid question. I guess some people want to receive raw constant data (e.g. hardwired string data) instead of hexadecimalized constant data, so I believe there is a requirement of such feature. But, I'm not sure if the case that the character encoding in ELF binary and that in current (terminal emulator's) locale are matched is common. I'm afraid that the mismatched case, like, encoding in binary is UCS2, UTF-16 or UTF-32 but the locale is UTF-8 would be popular (I'm not saying it's the most popular case). According to GCC manual: -fwide-exec-charset=charset Set the wide execution character set, used for wide string and character constants. The default is UTF-32 or UTF-16, whichever corresponds to the width of "wchar_t". As with -fexec-charset, charset can be any encoding supported by the system's "iconv" library routine; however, you will have problems with encodings that do not fit exactly in "wcha</pre> suzuki toshiya 2012-05-24T01:02:27 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gnu.binutils