[Bug gas/7026] New: ARM target wont build, error: format not a string literal and no format arguments

2008-11-12 Thread pwjansen at yahoo dot com
building arm-elf target,

Configured with,

 ../binutils-2.19/configure --target=arm-elf --prefix=/home/peter/arm/install
--enable-interwork --enable-multilib --disable-nls --disable-shared
--disable-threads --with-gcc --with-gnu-as --with-gnu-ld


Make stopps with the following message,

gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.19/gas -I. -I.
-I../../binutils-2.19/gas -I../bfd -I../../binutils-2.19/gas/config
-I../../binutils-2.19/gas/../include -I../../binutils-2.19/gas/..
-I../../binutils-2.19/gas/../bfd
-DLOCALEDIR="\"/home/peter/arm/install/share/locale\""   -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -c
../../binutils-2.19/gas/config/tc-arm.c
cc1: warnings being treated as errors
../../binutils-2.19/gas/config/tc-arm.c: In function ‘s_arm_unwind_save_mmxwr’:
../../binutils-2.19/gas/config/tc-arm.c:3459: error: format not a string literal
and no format arguments
../../binutils-2.19/gas/config/tc-arm.c:3473: error: format not a string literal
and no format arguments
../../binutils-2.19/gas/config/tc-arm.c: In function ‘s_arm_unwind_save_mmxwcg’:
../../binutils-2.19/gas/config/tc-arm.c:3591: error: format not a string literal
and no format arguments
../../binutils-2.19/gas/config/tc-arm.c:3606: error: format not a string literal
and no format arguments
../../binutils-2.19/gas/config/tc-arm.c: In function ‘s_arm_unwind_movsp’:
../../binutils-2.19/gas/config/tc-arm.c:3712: error: format not a string literal
and no format arguments
make[4]: *** [tc-arm.o] Error 1

The fix is quite easy,

--- binutils-2.19/gas/config/tc-arm.c   2008-08-13 09:39:30.0 +1000
+++ binutils-2.19-arm/gas/config/tc-arm.c   2008-11-12 19:51:08.0 
+1100
@@ -3456,7 +3456,7 @@
 
   if (reg == FAIL)
{
- as_bad (_(reg_expected_msgs[REG_TYPE_MMXWR]));
+ as_bad ("%s", _(reg_expected_msgs[REG_TYPE_MMXWR]));
  goto error;
}
 
@@ -3470,7 +3470,7 @@
  hi_reg = arm_reg_parse (&input_line_pointer, REG_TYPE_MMXWR);
  if (hi_reg == FAIL)
{
- as_bad (_(reg_expected_msgs[REG_TYPE_MMXWR]));
+ as_bad ("%s", _(reg_expected_msgs[REG_TYPE_MMXWR]));
  goto error;
}
  else if (reg >= hi_reg)
@@ -3588,7 +3588,7 @@
 
   if (reg == FAIL)
{
- as_bad (_(reg_expected_msgs[REG_TYPE_MMXWCG]));
+ as_bad ("%s", _(reg_expected_msgs[REG_TYPE_MMXWCG]));
  goto error;
}
 
@@ -3603,7 +3603,7 @@
  hi_reg = arm_reg_parse (&input_line_pointer, REG_TYPE_MMXWCG);
  if (hi_reg == FAIL)
{
- as_bad (_(reg_expected_msgs[REG_TYPE_MMXWCG]));
+ as_bad ("%s", _(reg_expected_msgs[REG_TYPE_MMXWCG]));
  goto error;
}
  else if (reg >= hi_reg)
@@ -3709,7 +3709,7 @@
   reg = arm_reg_parse (&input_line_pointer, REG_TYPE_RN);
   if (reg == FAIL)
 {
-  as_bad (_(reg_expected_msgs[REG_TYPE_RN]));
+  as_bad ("%s", _(reg_expected_msgs[REG_TYPE_RN]));
   ignore_rest_of_line ();
   return;
 }

-- 
   Summary: ARM target wont build,  error: format not a string
literal and no format arguments
   Product: binutils
   Version: 2.19
Status: NEW
  Severity: normal
  Priority: P2
 Component: gas
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: pwjansen at yahoo dot com
CC: bug-binutils at gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-elf


http://sourceware.org/bugzilla/show_bug.cgi?id=7026

--- 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/7026] ARM target wont build, error: format not a string literal and no format arguments

2008-11-12 Thread pwjansen at yahoo dot com

--- Additional Comments From pwjansen at yahoo dot com  2008-11-12 09:46 
---
Created an attachment (id=3058)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=3058&action=view)
patch to fix

Simple fix to ass "%s" as format string, problem with compiling with gcc-4.3.2

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=7026

--- 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/7027] New: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value

2008-11-12 Thread ro at TechFak dot Uni-Bielefeld dot DE
Trying to build current gcc mainline with GNU ld 2.19 fails linking the 64-bit
libstdc++.so.  When I retried with binutils mainline, the problems persists:

% /vol/gcc/obj/binutils-2.19.50-g/ld/ld-new -V -G -dy -z text -m elf64_sparc -Y
P,/usr/lib/sparcv9 -rpath-link /usr/lib/sparcv9 -Qy -o .libs/libstdc++.so.6.0.11
-L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/sparc-sun-solaris2.11/sparcv9/libstdc++-v3/src
-L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/sparc-sun-solaris2.11/sparcv9/libstdc++-v3/src/.libs
-L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/sparc-sun-solaris2.11/sparcv9/libstdc++-v3/src
-L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/sparc-sun-solaris2.11/sparcv9/libstdc++-v3/src/.libs
-L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9
-L/usr/ccs/lib/sparcv9 -L/lib/sparcv9 -L/usr/lib/sparcv9
-L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc -L/usr/ccs/lib
-L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9
-L/usr/ccs/lib/sparcv9 -L/lib/sparcv9 -L/usr/lib/sparcv9
-L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc -L/usr/ccs/lib
/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9/crti.o
/usr/ccs/lib/sparcv9/values-Xa.o
/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9/crtbegin.o
.libs/atomic.o .libs/bitmap_allocator.o .libs/pool_allocator.o
.libs/mt_allocator.o .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o
.libs/ctype.o .libs/debug.o .libs/functexcept.o .libs/hash.o .libs/hash_c++0x.o
.libs/globals_io.o .libs/hashtable.o .libs/hashtable_c++0x.o .libs/ios.o
.libs/ios_failure.o .libs/ios_init.o .libs/ios_locale.o .libs/limits.o
.libs/limits_c++0x.o .libs/list.o .libs/debug_list.o .libs/locale.o
.libs/locale_init.o .libs/locale_facets.o .libs/localename.o .libs/stdexcept.o
.libs/strstream.o .libs/system_error.o .libs/tree.o .libs/allocator-inst.o
.libs/concept-inst.o .libs/fstream-inst.o .libs/ext-inst.o .libs/ios-inst.o
.libs/iostream-inst.o .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o
.libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o
.libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o
.libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o .libs/mutex.o
.libs/condition_variable.o .libs/chrono.o .libs/thread.o .libs/atomicity.o
.libs/codecvt_members.o .libs/collate_members.o .libs/ctype_members.o
.libs/messages_members.o .libs/monetary_members.o .libs/numeric_members.o
.libs/time_members.o .libs/basic_file.o .libs/c++locale.o .libs/parallel_list.o
.libs/parallel_settings.o --whole-archive ../libmath/.libs/libmath.a
../libsupc++/.libs/libsupc++convenience.a --no-whole-archive -lm -lgcc_s
/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9/crtend.o
/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9/crtn.o -O1 -z relro
--gc-sections --version-script=libstdc++-symbols.ver -soname libstdc++.so.6
GNU ld (GNU Binutils) 2.19.50.2008
  Supported emulations:
   elf32_sparc
   elf64_sparc
.libs/atomic.o: could not read symbols: Bad value

Tracking this down (with an unoptimize ld compiled with -g only, because gdb
couldn't proper handle the -g -O2 binary), I found that bfd_set_error
(bfd_error_bad_value) is called from here:

#0  bfd_set_error (error_tag=bfd_error_bad_value) at
/vol/gnu/src/binutils/binutils-dist/bfd/bfd.c:425
#1  0x0008d130 in _bfd_sparc_elf_check_relocs (abfd=0x1dc510, info=0x19d978,
sec=0x1f6a20, relocs=0x1fdc10) at
/vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:1335
#2  0x000c4210 in elf_link_add_object_symbols (abfd=0x1dc510, info=0x19d978) at
/vol/gnu/src/binutils/binutils-dist/bfd/elflink.c:4722
#3  0x000c4dc8 in bfd_elf_link_add_symbols (abfd=0x1dc510, info=0x19d978) at
/vol/gnu/src/binutils/binutils-dist/bfd/elflink.c:5044
#4  0x0002e604 in load_symbols (entry=0x19dfc8, place=0xffbfe8d0) at
/vol/gnu/src/binutils/binutils-dist/ld/ldlang.c:2599
#5  0x0002f6b8 in open_input_bfds (s=0x19dfc8, force=0) at
/vol/gnu/src/binutils/binutils-dist/ld/ldlang.c:3028
#6  0x00037798 in lang_process () at
/vol/gnu/src/binutils/binutils-dist/ld/ldlang.c:6112
#7  0x0003ce4c in main (argc=114, argv=0xffbfea7c) at
/vol/gnu/src/binutils/binutils-dist/ld/ldmain.c:453

I.e. from bfd/elfxx-sparc.c (_bfd_sparc_elf_check_relocs), l. 1335.  At that
point, r_type = 18 (R_SPARC_WPLT30) and readelf on the problematic object
file reveals

% readelf -r .libs/atomic.o |grep R_SPARC_WPLT30
0014  000e0012 R_SPARC_WPLT30 .text + 0
0008  00180012 R_SPARC_WPLT30
atomic_flag_clear_expl + 0
0008  001b0012 R_SPARC_WPLT30
atomic_flag_test_and_s + 0
0008  001b0012 R_SPARC_WPLT30
atomic_flag_test_and_s + 0

It seems that a workaround similar to the ! ABI_64_P() case may be needed
for the 64-bit case as well.

-- 
   Summary: 64-bit libstdc++.so fails to link on Solaris 11/SPARC:
could not read symbols: Bad value
   Product: binutils
 

[Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted

2008-11-12 Thread ro at TechFak dot Uni-Bielefeld dot DE

--- Additional Comments From ro at TechFak dot Uni-Bielefeld dot DE  
2008-11-12 18:16 ---
Subject: Re:  ld is unable to link 32 bit libffi.so on gcc mainline: Memory 
exhausted

amodra at bigpond dot net dot au writes:

> --- Additional Comments From amodra at bigpond dot net dot au  2008-11-11 
> 23:46 ---
>   [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf 
> Al
>   [ 2] .symtab   SYMTAB   58 00 10   A  3   1 
>  1
> 
> Size of zero but sh_info of one??  That is quite broken.  How was this object
> file created?  If by gas, we have some other bug to fix.

By Sun as in a gcc mainline build:

% /vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/xgcc 
-B/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/ 
-B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/ 
-isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem 
/vol/gcc/sparc-sun-solaris2.11/sys-include -I. 
-I/vol/gcc/src/gcc-dist/libffi/include -Iinclude 
-I/vol/gcc/src/gcc-dist/libffi/src -g -O2 -c 
/vol/gcc/src/gcc-dist/libffi/src/sparc/v9.S  -fPIC -DPIC -o 
src/sparc/.libs/v9.o -v
 /vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/as -V -Qy -s -K PIC 
-xarch=v8plus -o src/sparc/.libs/v9.o v9.s
/usr/bin/as: Sun Compiler Common 12 SunOS_sparc snv_93 06/19/2008

v9.s is empty except for comments.

If I configure with gas 2.19, that is invoked as

 /vol/gcc/lib/gas-2.19 --gdwarf2 -v -V -Qy -s -K PIC -xarch=v8plus -o v9.o v9.s
GNU assembler version 2.19 (sparc-sun-solaris2.10) using BFD version (GNU 
Binutils) 2.19

and readelf -S gives

There are 7 section headers, starting at offset 0x60:

Section Headers:
  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf Al
  [ 0]   NULL 00 00 00  0   0  0
  [ 1] .text PROGBITS 34 00 00  AX  0   0  1
  [ 2] .data PROGBITS 34 00 00  WA  0   0  1
  [ 3] .bss  NOBITS   34 00 00  WA  0   0  1
  [ 4] .shstrtab STRTAB   34 2c 00  0   0  1
  [ 5] .symtab   SYMTAB   000178 40 10  6   4  4
  [ 6] .strtab   STRTAB   0001b8 01 00  0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

But even if Sun as is broken here (and I can file a bug report for that),
gld shouldn't try to allocate an infinite amount of memory.

Rainer



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=7023

--- 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/7028] New: valgrind complaints running ld-elf/header

2008-11-12 Thread hp at sourceware dot org
For all the targets above, I see in ld.log:
Executing on host: sh -c {valgrind -q /home/hp/binutils/obj/l/ld/ld-new 
-L/home/hp/binutils/src/ld/testsuite/ld-elf  -T header.t -z max-page-size=0x100
-o tmpdir/dump tmpdir/dump0.o 2>&1}  /dev/null ld.tmp (timeout = 300)
==2996== Syscall param write(buf) points to uninitialised byte(s)
==2996==at 0x875F73: __write_nocancel (in /lib/libc-2.8.so)
==2996==by 0x8121F6: _IO_do_write@@GLIBC_2.1 (in /lib/libc-2.8.so)
==2996==by 0x811BCF: _IO_file_overflow@@GLIBC_2.1 (in /lib/libc-2.8.so)
==2996==by 0x812F08: _IO_switch_to_get_mode (in /lib/libc-2.8.so)
==2996==by 0x8115C7: _IO_file_seekoff@@GLIBC_2.1 (in /lib/libc-2.8.so)
==2996==by 0x807D7F: _IO_seekoff_unlocked (in /lib/libc-2.8.so)
==2996==by 0x80F004: fseeko64 (in /lib/libc-2.8.so)
==2996==by 0x806B407: bfd_seek (bfdio.c:365)
==2996==by 0x809F1CE: elf_link_flush_output_syms (elflink.c:8153)
==2996==by 0x80AAB97: bfd_elf_final_link (elflink.c:10619)
==2996==by 0x805E193: ldwrite (ldwrite.c:567)
==2996==by 0x805D5D3: main (ldmain.c:462)
==2996==  Address 0x400c020 is not stack'd, malloc'd or (recently) free'd
succeeded with: <(repeated)>, expected: <>
(the above repeated again for unknown reasons)
FAIL: ld-elf/header

Looks like a target-independent bug; something or other is left uninitialized.

-- 
   Summary: valgrind complaints running ld-elf/header
   Product: binutils
   Version: 2.20 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: hp at sourceware dot org
CC: bug-binutils at gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: cris-axis-linux-gnu, arm-unknown-linux-gnu, i686-pc-
linux-gnu


http://sourceware.org/bugzilla/show_bug.cgi?id=7028

--- 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/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted

2008-11-12 Thread amodra at bigpond dot net dot au

--- Additional Comments From amodra at bigpond dot net dot au  2008-11-12 
22:07 ---
http://sourceware.org/ml/binutils-cvs/2008-11/msg00052.html
http://sourceware.org/ml/binutils/2008-11/msg00123.html

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=7023

--- 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/7028] valgrind complaints running ld-elf/header

2008-11-12 Thread hp at sourceware dot org

--- Additional Comments From hp at sourceware dot org  2008-11-13 00:52 
---
Looks like SIZEOF_HEADERS oscillating between 32 and 64 is part of the problem,
see ld/emultempl/elf-generic.em:gld${EMULATION_NAME}_map_segments.
Then, the place that allocates space for headers allocates a different amount
than is output, for the test-case.  Patch in testing.

-- 
   What|Removed |Added

 Status|NEW |ASSIGNED


http://sourceware.org/bugzilla/show_bug.cgi?id=7028

--- 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/7028] valgrind complaints running ld-elf/header

2008-11-12 Thread hp at sourceware dot org


-- 
   What|Removed |Added

 AssignedTo|unassigned at sources dot   |hp at sourceware dot org
   |redhat dot com  |


http://sourceware.org/bugzilla/show_bug.cgi?id=7028

--- 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/7028] valgrind complaints running ld-elf/header

2008-11-12 Thread hp at sourceware dot org

--- Additional Comments From hp at sourceware dot org  2008-11-13 03:10 
---
Committed .

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=7028

--- 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