[Bug binutils/6832] Crash while handling DW_AT_abstract_origin for a last comp unit
--- Additional Comments From divis1969 at gmail dot com 2009-12-11 14:19 --- Hi, While running my program with BFD 2.20.51.20090916 (which I had grabbed from GDB 7.0) I see there is still a possibility for the problem reported by this bug. It does not crash but produces a message like Dwarf Error: Could not find abbrev number The problem, on my mind, is caused by the following sequence: My program tries to locate an address and find the line number, function etc. The ELF file has just one debug info section. One of the comp unit was already loaded (by parse_comp_unit() I suppose) but scan_unit_for_symbols() was not yet called yet for it. At some stage, all the comp units of this alone sections are loaded and parsed and stash->sec_info_ptr was advanced to the end of this section (line 3224 of dwarf2.c) Finally, when find_line tries to find locate some address in this unit and scan_unit_for_symbols is called, it produces such an error message. This happens when find_abstract_instance_name() tries to read some attribute, referred by DW_FORM_ref_addr. It tries to read from beyond the scope of the debug info section due to line 1751: info_ptr = unit->stash->sec_info_ptr + die_ref; As I said before, unit->stash->sec_info_ptr is pointing to the end if section. Dmitry -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://sourceware.org/bugzilla/show_bug.cgi?id=6832 --- 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/11083] New: Gold does not supports -G option for creating shared libs
Gold linker doesnt handle the typical svr4 option -G vfor creating shared objects. As this option (-G) is implemented for most systems in GNU libtool it can be a problem for some systems. -- Summary: Gold does not supports -G option for creating shared libs Product: binutils Version: 2.20 Status: NEW Severity: enhancement Priority: P3 Component: gold AssignedTo: ian at airs dot com ReportedBy: takis at xfree86 dot org CC: bug-binutils at gnu dot org GCC target triplet: (Any) http://sourceware.org/bugzilla/show_bug.cgi?id=11083 --- 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/11084] New: Gold issue on handling shared objects where objdump -T is empty
Gold cannt seem to handle at all dynamic objects (on the final linking stage) if the dynamic table is not present. (aka objdump -T libfoo.so is empty) Gnu linker version 2.15 and 2.20 however they dont seem to have a problem with that issue linkinmg will go through fine. -- Summary: Gold issue on handling shared objects where objdump -T is empty Product: binutils Version: 2.20 Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: ian at airs dot com ReportedBy: takis at xfree86 dot org CC: bug-binutils at gnu dot org GCC host triplet: EMC Unix http://sourceware.org/bugzilla/show_bug.cgi?id=11084 --- 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/11083] Gold does not supports -G option for creating shared libs
--- Additional Comments From takis at xfree86 dot org 2009-12-11 16:41
---
simple solution (not implementing the most complicated -G size as gnu ld, jusr
-G as its used on a typical SVR4)
options.h
+ DEFINE_bool(G, options::ONE_DASH, '\0', false,
+ N_("Generate shared library"), NULL);
options.cc
- if (this->Bshareable())
+ if ( (this->Bshareable()) || (this->G()) )
+this->set_shared(true);
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11083
--- 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 ld/11085] New: Incorrect address calculation for Microblaze assembler code when using -relax and --gc-sections options
When linking object files using the options --gc-sections and -relax (MicroBlaze specific option that removes superfluous "imm 0" instructions), the addresses for some labels are miscalculated. Apparently this problem is caused by removing the "imm 0" instructions without changing the labels' addresses accordingly (e.g., when 2 "imm 0" instructions are removed, the address is off by 2 instructions). It seems this only occurs in files generated from assembler source code. We did not notice this behavior in linked object files compiled from C/C++ Code. gcc/g++ by default passes -relax to ld when compiling for microblaze, so many users may be unaware of what causes that but. The effect shows when using ld compiled from the current version out of cvs (GNU ld (GNU Binutils) 2.20.51.20091211) as well as older versions (e.g., 2.16) distributed with Xilinx EDK 10 and 11. Code example: Without using the -relax option, objdump shows the correct code: 0050 <_myStart>: 50: 8000or r0, r0, r0 54: 8000or r0, r0, r0 58: b000imm 0 5c: b9f40028brlid r15, 40 // 84 60: b80cbri 12 // 6c <_bla> 64: 8000or r0, r0, r0 68: b800ffe8bri -24 // 50 <_TEXT_START_ADDR> 006c <_bla>: 6c: b800bri 0 // 6c <_bla> 0070 <_foobar>: 70: 32e0002aaddik r23, r0, 42 74: 32e00017addik r23, r0, 23 78: 8000or r0, r0, r0 Using both -relax and --gc-sections the objdump shows: 0050 <_myStart>: 50: 8000or r0, r0, r0 54: 8000or r0, r0, r0 58: b9f40028brlid r15, 40 // 80 5c: b810bri 16 // 6c <_bla> 60: 8000or r0, r0, r0 64: b800ffecbri -20 // 50 <_TEXT_START_ADDR> 68: b804bri 4 // 6c <_bla> 006c <_bla>: 6c: 32e0002aaddik r23, r0, 42 0070 <_foobar>: 70: 32e00017addik r23, r0, 23 74: 8000or r0, r0, r0 Both labels _bla and _foobar are at the wrong address. -- Summary: Incorrect address calculation for Microblaze assembler code when using -relax and --gc-sections options Product: binutils Version: 2.20 Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: michael dot engel at tu-dortmund dot de CC: bug-binutils at gnu dot org GCC host triplet: i386-pc-linux-gnu GCC target triplet: microblaze-unknown-none http://sourceware.org/bugzilla/show_bug.cgi?id=11085 --- 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/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-11 17:12 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries I think instructions like these below should have a comment flagging them as UNPREDICTABLEstrh can't have Rd == R15. 3c2c0: f0b0strheq pc, [r0], -r0 3fc2f8: 000ff0bestrheq pc, [pc], -lr cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- 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/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-11 17:25 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries I don't think the following is UNPREDICTABLE. Every load and store that has Rd == Rn isn't UNPREDICTABLE. That only applies if the W and P bits are set. Or, if it is one of the "t" variants like strt. 2fc:004000bfstrheq r0, [r0], #-15 ; cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- 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/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-11 17:35 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries I don't see why this one is marked UNPREDICTABLE... 42fc: 005010bf ldrheq r1, [r0], #-15 ; The P and W bits are both zero which is ok. cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- 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/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From drow at false dot org 2009-12-11 17:48 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Fri, Dec 11, 2009 at 05:25:25PM -, chris at seberino dot org wrote: > I don't think the following is UNPREDICTABLE. Every load and store that has > Rd == Rn isn't UNPREDICTABLE. That only applies if the W and P bits are set. > Or, if it is one of the "t" variants like strt. > > 2fc:004000bfstrheq r0, [r0], #-15 ; My copy of the manual doesn't say this is unpredictable - but it doesn't say what it means, either. The valid versions all have P == 1 and/or W == 1. And the post-indexed encoding is the same as strht encoding. I'm not quite sure what that adds up to! -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- 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/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-11 17:58 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Fri, Dec 11, 2009 at 05:48:59PM -, drow at false dot org wrote: > My copy of the manual doesn't say this is unpredictable - but it > doesn't say what it means, either. The valid versions all have P == 1 > and/or W == 1. And the post-indexed encoding is the same as strht > encoding. > > I'm not quite sure what that adds up to! Oh no. I'll check later but an unspecified instruction would be bad for us. cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- 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/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-11 18:17 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Fri, Dec 11, 2009 at 05:48:59PM -, drow at false dot org wrote: > > --- Additional Comments From drow at false dot org 2009-12-11 17:48 > --- > Subject: Re: Bug in objdump when disassembling raw > armv4t binaries > > On Fri, Dec 11, 2009 at 05:25:25PM -, chris at seberino dot org wrote: > > I don't think the following is UNPREDICTABLE. Every load and store that has > > Rd == Rn isn't UNPREDICTABLE. That only applies if the W and P bits are > > set. > > Or, if it is one of the "t" variants like strt. > > > > 2fc:004000bfstrheq r0, [r0], #-15 ; > > My copy of the manual doesn't say this is unpredictable - but it > doesn't say what it means, either. I think unspecified should be flagged as UNPREDICTABLE since we can't predict what it will do. cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- 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 gas/11086] New: build failed
../../gas/config/tc-rx.c: In function rx_equ: ../../gas/config/tc-rx.c:898: error: declaration of expr shadows a global declaration ../../gas/expr.h:173: error: shadowed declaration is here -- Summary: build failed Product: binutils Version: 2.21 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassigned at sources dot redhat dot com ReportedBy: ysato at users dot sourceforge dot jp CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=11086 --- 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 gas/11086] build failed
--- Additional Comments From ysato at users dot sourceforge dot jp 2009-12-11 20:53 --- Created an attachment (id=4465) --> (http://sourceware.org/bugzilla/attachment.cgi?id=4465&action=view) simply fix. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11086 --- 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
