Re: -al
Hi George,
I have been using the -al=file to generate assembler listing files. In
version 2.16 this is being interpreted as --alternate.
Oops - sorry - please ignore my previous post. I missed that you were
using the '=file' syntax. When I added that to the command line of my
2.16 test build I was able to reproduce your problem.
Please could you try the attached patch. I believe that it will resolve
the problem.
Cheers
Nick
gas/ChangeLog
2006-03-08 Nick Clifton <[EMAIL PROTECTED]>
* as.c (parse_args): Add an entry for "al" to prevent -al from
being confused with --alternate.
Index: gas/as.c
===
RCS file: /cvs/src/src/gas/as.c,v
retrieving revision 1.58
diff -c -3 -p -r1.58 as.c
*** gas/as.c 3 Mar 2005 01:29:52 - 1.58
--- gas/as.c 8 Mar 2006 10:06:32 -
*** parse_args (int * pargc, char *** pargv)
*** 437,447
the end of the preceeding line so that it is simpler to
selectively add and remove lines from this list. */
{"alternate", no_argument, NULL, OPTION_ALTERNATE}
! /* The entry for "a" is here to prevent getopt_long_only() from
!considering that -a is an abbreviation for --alternate. This is
!necessary because -a= is a valid switch but getopt would
!normally reject it since --alternate does not take an argument. */
,{"a", optional_argument, NULL, 'a'}
,{"defsym", required_argument, NULL, OPTION_DEFSYM}
,{"dump-config", no_argument, NULL, OPTION_DUMPCONFIG}
,{"emulation", required_argument, NULL, OPTION_EMULATION}
--- 437,448
the end of the preceeding line so that it is simpler to
selectively add and remove lines from this list. */
{"alternate", no_argument, NULL, OPTION_ALTERNATE}
! /* The next two entries are here to prevent getopt_long_only() from
!considering that -a or -al is an abbreviation for --alternate.
!This is necessary because -a= is a valid switch but getopt
!would normally reject it since --alternate does not take an argument. */
,{"a", optional_argument, NULL, 'a'}
+ ,{"al", optional_argument, NULL, 'a'}
,{"defsym", required_argument, NULL, OPTION_DEFSYM}
,{"dump-config", no_argument, NULL, OPTION_DUMPCONFIG}
,{"emulation", required_argument, NULL, OPTION_EMULATION}
*** main (int argc, char ** argv)
*** 1205,1211
keep_it = 0;
if (!keep_it)
! unlink_if_ordinary (out_file_name);
input_scrub_end ();
--- 1206,1212
keep_it = 0;
if (!keep_it)
! unlink (out_file_name);
input_scrub_end ();
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/2442] New: ld slow with many local relocs (O(N^2) in get_dyn_sym_info)
I can't provide the .o files exhibiting this problem, hence I have to just give my analysis. We have a case where there are big object files containing many of such relocations: 00030328 042c0027 R_IA64_DIR64LSB .text + 2ee51 00030330 042c0027 R_IA64_DIR64LSB .text + 2ed41 00030338 042c0027 R_IA64_DIR64LSB .text + 2ee41 Thousands of them. The special thing here is, many relocations against the same symbol (here a local pseudo symbol for .text) but differing addends. The ia64 linker in elfNN_ia64_check_relocs goes over all relocs, calling get_dyn_sym_info() on each one. For local symbols (as is the case here) this collects a linked list of elfNN_ia64_dyn_sym_info entries _for each addend_ without duplicates. As this is a linked list just checking for duplicates is O(N^2) in the number of such relocs. The above relocs specifically where in the .rela.debug_ranges section, so in this case it's debug info which leads to ld breaking down. Linking the specific .o files in question needs many hours it seems (I wasn't yet patient enough to really leave it running through the end), but in gdb one can see that elfNN_ia64_check_relocs doesn't finish for a long time. The O(N^2) is quite obvious, but I don't know yet if that's the only cause for the huge reported link time. -- Summary: ld slow with many local relocs (O(N^2) in get_dyn_sym_info) Product: binutils Version: 2.17 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: matz at suse dot de CC: bug-binutils at gnu dot org GCC target triplet: ia64-linux http://sourceware.org/bugzilla/show_bug.cgi?id=2442 --- 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
Re: -al
On Wed, Mar 08, 2006 at 10:19:56AM +, Nick Clifton wrote: > *** main (int argc, char ** argv) > *** 1205,1211 > keep_it = 0; > > if (!keep_it) > ! unlink_if_ordinary (out_file_name); > > input_scrub_end (); > > --- 1206,1212 > keep_it = 0; > > if (!keep_it) > ! unlink (out_file_name); > > input_scrub_end (); > Is this bit unrelated? -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/2442] ld slow with many local relocs (O(N^2) in get_dyn_sym_info)
-- What|Removed |Added CC||pth at suse dot de http://sourceware.org/bugzilla/show_bug.cgi?id=2442 --- 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/2443] Dwarf support in ld is broken
--- Additional Comments From hjl at lucon dot org 2006-03-10 20:40 --- The problem is <2><4ef9>: Abbrev Number: 52 (DW_TAG_inlined_subroutine) DW_AT_abstract_origin: <4f18> DW_AT_ranges : 0x3e0 DW_AT_call_file : 0 DW_AT_call_line : 0 According to DWARF 3, 0 means no source file has been specified. The same applies to DW_AT_call_line. -- http://sourceware.org/bugzilla/show_bug.cgi?id=2443 --- 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/2443] Dwarf2 reader doesn't handle file 0 correctly
--- Additional Comments From hjl at lucon dot org 2006-03-10 20:54 --- A patch is posted at http://sourceware.org/ml/binutils/2006-03/msg00143.html -- What|Removed |Added Summary|Dwarf support in ld is |Dwarf2 reader doesn't handle |broken |file 0 correctly http://sourceware.org/bugzilla/show_bug.cgi?id=2443 --- 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/2443] New: Dwarf support in ld is broken
[EMAIL PROTECTED] binutils]$ gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -o nm-new nm.o budemang.o bucomm.o version.o filemode.o ../bfd/.libs/libbfd.a ../libiberty/libiberty.a -B./ ./ld: Dwarf Error: mangled line number section (bad file number). ./ld: Dwarf Error: mangled line number section (bad file number). ./ld: Dwarf Error: mangled line number section (bad file number). ./ld: Dwarf Error: mangled line number section (bad file number). ./ld: Dwarf Error: mangled line number section (bad file number). ./ld: Dwarf Error: mangled line number section (bad file number). ./ld: Dwarf Error: mangled line number section (bad file number). ./ld: Dwarf Error: mangled line number section (bad file number). ./ld: Dwarf Error: mangled line number section (bad file number). ./ld: Dwarf Error: mangled line number section (bad file number). bucomm.o: In function `make_tempname':/export/gnu/src/binutils-import/binutils/binutils/bucomm.c:426: warning: the use of `mktemp' is dangerous, better use `mkstemp' -- Summary: Dwarf support in ld is broken Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: hjl at lucon dot org CC: bug-binutils at gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://sourceware.org/bugzilla/show_bug.cgi?id=2443 --- 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/2412] New: DOCUMENTATION BUG
The pseudo operation: 1) [EMAIL PROTECTED] 2) [EMAIL PROTECTED] 2) [EMAIL PROTECTED] and those for 64bit PowerPc architecture family are not documented. Those pseudo operation are used usually in a macro for loading and immediate operand of 32bit (or 64bit) into a machine register because it is not possible to do that with a single instruction on a RISC processor. Let me point out that analogous features are documented, for example, in the case of the V850 processor, so I really think that the same should be done for the PowerPc. Many thanks -- Summary: DOCUMENTATION BUG Product: binutils Version: 2.16 Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassigned at sources dot redhat dot com ReportedBy: anton dot soppelsa at igi dot cnr dot it CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=2412 --- 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/2404] Linker failed to handle symbols with mismatched types.
--- Additional Comments From hjl at lucon dot org 2006-02-28 21:37 --- Created an attachment (id=894) --> (http://sourceware.org/bugzilla/attachment.cgi?id=894&action=view) A testcase [EMAIL PROTECTED] mismatch]$ make CC=gcc gcc -O -g -c -o foo.o foo.c gcc -O -g -fPIC -c -o bar.o bar.c gcc -o libbar.so -shared bar.o gcc -o foo foo.o libbar.so -Wl,-rpath,. ./foo times: -1 times: 20 time: 0 time: 10 make: *** [all] Segmentation fault [EMAIL PROTECTED] mismatch]$ -- http://sourceware.org/bugzilla/show_bug.cgi?id=2404 --- 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/2434] ld --as-needed causes BFD internal error
--- Additional Comments From ldv at altlinux dot org 2006-03-10 23:39 --- The test fails exactly the same way on FC-devel too (binutils-2.16.91.0.6-4, gcc-c++-4.1.0-3). -- http://sourceware.org/bugzilla/show_bug.cgi?id=2434 --- 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/2362] SH: Hidden symbol in DSO does not be forced local
--- Additional Comments From sugioka at itonet dot co dot jp 2006-02-25 02:00 --- I am saying that hidden symbol should not be globalized by vesion script. On x86, hidden symbols can not be globalized even if they appeared in global section of the version script, But on SH, they can be globalized and the result is segmentation fault. So it should be explicitly disabled as x86 do in bfd libs. I found this problem while building glib-2.9.2. -- http://sourceware.org/bugzilla/show_bug.cgi?id=2362 --- 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/2402] New: strip fail sometime to strip libc-2.3.5.so with signal11
With binutils-2.16.91.0.5 and 2.16.91.0.6, sometime strip fail
When it work
/tools/bin/find /lib /usr/lib /usr/share/rrdtool-* /install/initrd/lib \
-type f \( -name '*.so' -o -name '*.so[\.0-9]*' \) \
-ls -exec /tools/bin/strip --strip-all {} \; #2>/dev/null
1137622 4640 -rwxr-xr-x 1 root root 4735243 Feb 25 12:06 /lib/libc-
2.3.5.so
1135963 328 -rwxr-xr-x 1 root root 329306 Feb 25 12:06 /lib/ld-
2.3.5.so
1135780 12 -rwxr-xr-x 1 root root 9592 Feb 25
12:05 /lib/libBrokenLocale-2.3.5.so
1135795 460 -rwxr-xr-x 1 root root 465024 Feb 25 12:05 /lib/libm-
2.3.5.so
...
(only libc was not yet stripped)
Then after many strip attempts
/tools/bin/find /lib /usr/lib /usr/share/rrdtool-* /install/initrd/lib \
-type f \( -name '*.so' -o -name '*.so[\.0-9]*' \) \
-ls -exec /tools/bin/strip --strip-all {} \; #2>/dev/null
1126113 1020 -rwxr-xr-x 1 root root 1036728 Feb 25 12:44 /lib/libc-
2.3.5.so
/tools/bin/find: /tools/bin/strip terminated by signal 11
1126116 84 -rwxr-xr-x 1 root root80716 Feb 25 12:44 /lib/ld-
2.3.5.so
11357758 -rwxr-xr-x 1 root root 5528 Feb 25
12:44 /lib/libBrokenLocale-2.3.5.so
1135795 140 -rwxr-xr-x 1 root root 137848 Feb 25 12:44 /lib/libm-
2.3.5.so
...
It look to corrupt libc-2.3.5.so. Any next attempt to strip again fail with the
same signal 11 until glibc is rebuild. Then after the rebuild, it work most of
the time. To be certain to reproduce the bug, I had to repeat the strip script
in a `seq 1 20`loop.
All of the build is made similary to LFS-6.1 build (except binutil upgrade and
stripping shared lib is not written in the book, but has been work for time
with older LFS5.1 and strip 2.15.90.0.3 20040415)
strip part is made in a chroot inside the build environnement.
--
Summary: strip fail sometime to strip libc-2.3.5.so with signal11
Product: binutils
Version: 2.16
Status: NEW
Severity: normal
Priority: P2
Component: binutils
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: g dot esp at free dot fr
CC: bug-binutils at gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://sourceware.org/bugzilla/show_bug.cgi?id=2402
--- 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/2257] objdump can't recognize CISCO ELF
--- Additional Comments From alec at sensi dot org 2006-02-23 18:29 --- This file is good for CISCO and works just fine. Unfortunately, I can't upload it due to (c) issue. As far as I understand, this file is *very* simplified MIPS ELF and has no .shstrtab section at all (only bare ELF headers). So, all ELF sections are nameless. See a `readelf` output. Is it possible to use Binutils with such files ? -- http://sourceware.org/bugzilla/show_bug.cgi?id=2257 --- 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
Re: [Bug ld/2378] Incorrect opcode in __do_clear_bss if bss has more than 15 bytes
Hi Ken, avr-as a.S -o a.o avr-ld -m avr4 -Tdata 0x800100 -o a.elf a.o avr-objdump -d a.elf > a.lst avr-ld -m avr4 -Tdata 0x800100 -o a.hex --oformat=ihex a.o The list file shows both opcodes correctly, "a0 31". But in the hex file the first one is wrong, "B031", while the second one is correct, "A031". The difference is that avr-ld had to do a relocation for the first one. Running "avr-objdump -r a.o" shows one record with type R_AVR_LO8_LDI relocation, value __bss_end. R_AVR_LO8_LDI is performed in binutils-2.16.1/bfd/elf32-avr.c. It works correctly for the default ELF format, but fails for the IHEX format. This is progress, but I'm still stumped. It is quite common that LD is unable to correctly translate binary file formats and link at the same time. Quite a few targets suffer from this problem. The simplest workaround is to perform the link first and then use objcopy to perform the binary translation. ie: avr-ld -m avr4 -Tdata 0x800100 -o a.elf a.o avr-objcopy --output-target ihex a.elf a.ihex Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: -al
On Fri, Mar 10, 2006 at 08:40:18PM -0500, George M. Gallant, Jr. wrote: > Daniel, > > I don't understand the context of you question. The patch from Nick > seems to > fix my concern. Right - it was directed at Nick. -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: -al
Daniel, I don't understand the context of you question. The patch from Nick seems to fix my concern. George On Fri, 2006-03-10 at 13:22 -0500, Daniel Jacobowitz wrote: On Wed, Mar 08, 2006 at 10:19:56AM +, Nick Clifton wrote: > *** main (int argc, char ** argv) > *** 1205,1211 > keep_it = 0; > > if (!keep_it) > ! unlink_if_ordinary (out_file_name); > > input_scrub_end (); > > --- 1206,1212 > keep_it = 0; > > if (!keep_it) > ! unlink (out_file_name); > > input_scrub_end (); > Is this bit unrelated? ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
