[Bug binutils/17531] readelf crashes on fuzzed samples

[cherepan at mccme dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=17531

Alexander Cherepanov  changed:

   What|Removed |Added

Summary|readelf -a crashes on   |readelf crashes on fuzzed
   |fuzzed samples  |samples

-- 
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/17512] libbfd/binutils: crashes on fuzzed samples

[cherepan at mccme dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=17512

Alexander Cherepanov  changed:

   What|Removed |Added

Summary|segfault in PE parser / |libbfd/binutils: crashes on
   |_bfd_pei_swap_aouthdr_in|fuzzed samples

-- 
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: Error in bfd/doc/Makefile

[Nicholas Clifton]

Hi Stephen,


It appears within the bfd/doc makefile it Assumes CC=pcc correctly but sets
CC_FOR_BUILD = gcc which is nowhere on the system. This creates the below
error when compiling binutils on a musl-pcc system. Setting CC_FOR_BUILD =
pcc manually allows chew to build.


I think that the intention is that CC_FOR_BUILD should be set by the 
user, if they are cross-compiling a toolchain.


The logic to choose CC_FOR_BUILD can be found in bfd/acinclude.m4:

  AC_DEFUN([BFD_CC_FOR_BUILD],
  [# Put a plausible default for CC_FOR_BUILD in Makefile.
  if test -z "$CC_FOR_BUILD"; then
if test "x$cross_compiling" = "xno"; then
  CC_FOR_BUILD='$(CC)'
else
  CC_FOR_BUILD=gcc
fi
  fi

So, if the CC_FOR_BUILD is not set, and if this is a cross-compilation, 
then gcc is used as a last resort.  The implication is that CC is for 
native builds whereas CC_FOR_BUILD is for cross builds.


Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: GAS for ARM: does not support BX instruction for ARMv3 and lower

[Nicholas Clifton]

Hi Sergey,


I try to compile program for ARMv3 or ARMv2 CPU target using GCC (4.8.x).
It produces assembler code with BX LR instructions (return from function)
which GAS (2.23.2) cannot compile:
Error: selected processor does not support ARM mode `bx lr'


This is really a gcc bug.  ARM architectures before v4T do not support 
the BX instruction, and so gcc should not be generating it.




It is work for ARMv4 mode and greater (ARMv4 has no BX  instruction
support, but GAS compiles it as MOV PC,).


You could try adding "--fix-v4bx" (or -Wa,--fix-v4bx) to your command 
line, but whilst this will allow the instruction to be assembled, it 
will not convert it into a MOV PC, LR instruction.




As I know BX  is strongly recommended to be used instead of MOV
PC, by the ARM architecture manual (section A.4.1.1).


True - although I think that the ARM ARM also assumes that you will be 
using a newer architecture - v2 and v3 are very old now.


Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/17742] ABI version 1 is not compatible with ABI version 0 output

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17742

--- Comment #1 from Alan Modra  ---
How did you manage that?  Here's what I see on my powerpc64 box, using a
freshly compiled binutils-2.25 for the final link and recent trunk binutils for
the rest.

[alan@squeak bin-225]$ echo 'int x;' > foo.c
[alan@squeak bin-225]$ gcc -shared -o foo.so foo.c
[alan@squeak bin-225]$ gcc -c foo.c
[alan@squeak bin-225]$ readelf -h foo.o | grep Flags:
  Flags: 0x0
[alan@squeak bin-225]$ readelf -h foo.so | grep Flags:
  Flags: 0x1, abiv1
[alan@squeak bin-225]$ ld/ld-new -shared --eh-frame-hdr foo.o foo.so
[alan@squeak bin-225]$ readelf -h a.out | grep Flags:
  Flags: 0x1, abiv1

-- 
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: objdump man page lines too long

[Nicholas Clifton]

Hi Dan,


nobody@jidanni3:/$ < /dev/null > /dev/null man objdump
:170: warning [p 1, 5.5i]: can't break line
:611: warning [p 6, 8.0i, div `an-div', 0.0i]: can't break line


I have checked in the attached patch to fix these warnings.

Cheers
  Nick

binutils/ChangeLog
2014-12-23  Nick Clifton  

* doc/binutils.texi (objdump): Reformat to avoid overlong lines.


diff --git a/binutils/doc/binutils.texi b/binutils/doc/binutils.texi
index 39eb1d2..5842a91 100644
--- a/binutils/doc/binutils.texi
+++ b/binutils/doc/binutils.texi
@@ -1858,7 +1858,10 @@ objdump [@option{-a}|@option{--archive-headers}]
 [@option{-R}|@option{--dynamic-reloc}]
 [@option{-s}|@option{--full-contents}]
 [@option{-W[lLiaprmfFsoRt]}|
- @option{--dwarf}[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames-interp,=str,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges,=gdb_index]]
+ @option{--dwarf}[=rawline,=decodedline,=info,=abbrev,=pubnames]
+ [=aranges,=macro,=frames,=frames-interp,=str,=loc]
+ [=Ranges,=pubtypes,=trace_info,=trace_abbrev]
+ [=trace_aranges,=gdb_index]
 [@option{-G}|@option{--stabs}]
 [@option{-t}|@option{--syms}]
 [@option{-T}|@option{--dynamic-syms}]
@@ -2095,19 +2098,35 @@ compilers.
 For the x86, some of the options duplicate functions of the @option{-m}
 switch, but allow finer grained control.  Multiple selections from the
 following may be specified as a comma separated string.
-@option{x86-64}, @option{i386} and @option{i8086} select disassembly for
-the given architecture.  @option{intel} and @option{att} select between
-intel syntax mode and AT&T syntax mode.
-@option{intel-mnemonic} and @option{att-mnemonic} select between
-intel mnemonic mode and AT&T mnemonic mode. @option{intel-mnemonic}
-implies @option{intel} and @option{att-mnemonic} implies @option{att}.
-@option{addr64}, @option{addr32},
-@option{addr16}, @option{data32} and @option{data16} specify the default
-address size and operand size.  These four options will be overridden if
-@option{x86-64}, @option{i386} or @option{i8086} appear later in the
-option string.  Lastly, @option{suffix}, when in AT&T mode,
-instructs the disassembler to print a mnemonic suffix even when the
-suffix could be inferred by the operands.
+@table @code
+@item x86-64
+@itemx i386
+@itemx i8086
+Select disassembly for the given architecture.
+
+@item intel
+@itemx att
+Select between intel syntax mode and AT&T syntax mode.
+
+@item intel-mnemonic
+@itemx att-mnemonic
+Select between intel mnemonic mode and AT&T mnemonic mode.
+Note: @code{intel-mnemonic} implies @code{intel} and
+@code{att-mnemonic} implies @code{att}.
+
+@item addr64
+@itemx addr32
+@itemx addr16
+@itemx data32
+@itemx data16
+Specify the default address size and operand size.  These four options
+will be overridden if @code{x86-64}, @code{i386} or @code{i8086}
+appear later in the option string.
+
+@item suffix
+When in AT&T mode, instructs the disassembler to print a mnemonic
+suffix even when the suffix could be inferred by the operands.
+@end table
 
 For PowerPC, @option{booke} controls the disassembly of BookE
 instructions.  @option{32} and @option{64} select PowerPC and
@@ -2191,10 +2210,24 @@ Print information that is specific to the object file format.  The
 argument @var{options} is a comma separated list that depends on the
 format (the lists of options is displayed with the help).
 
-For XCOFF, the available options are: @option{header}, @option{aout},
-@option{sections}, @option{syms}, @option{relocs}, @option{lineno},
-@option{loader}, @option{except}, @option{typchk}, @option{traceback},
-@option{toc} and @option{ldinfo}.
+For XCOFF, the available options are:
+@table @code
+@item header
+@item aout
+@item sections
+@item syms
+@item relocs
+@item lineno,
+@item loader
+@item except
+@item typchk
+@item traceback
+@item toc
+@item ldinfo
+@end table
+
+Not all object formats support this option.  In particular the ELF
+format does not use it.
 
 @item -r
 @itemx --reloc
@@ -2251,7 +2284,10 @@ Display @var{width} bytes on a single line when disassembling
 instructions.
 
 @item -W[lLiaprmfFsoRt]
-@itemx --dwarf[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames-interp,=str,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges,=gdb_index]
+@itemx --dwarf[=rawline,=decodedline,=info,=abbrev,=pubnames]
+@itemx --dwarf[=aranges,=macro,=frames,=frames-interp,=str,=loc]
+@itemx --dwarf[=Ranges,=pubtypes,=trace_info,=trace_abbrev]
+@itemx --dwarf[=trace_aranges,=gdb_index]
 @cindex DWARF
 @cindex debug symbols
 Displays the contents of the debug sections in the file, if any are
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/17742] ABI version 1 is not compatible with ABI version 0 output

[sch...@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17742

Andreas Schwab  changed:

   What|Removed |Added

 CC||matz at suse dot de

--- Comment #2 from Andreas Schwab  ---
This is strange.  The error is coming from

and I can reproduce the problem with the binutils used there for building
(which was cut from commit 89e0345), but I cannot reproduce it when I try it
with the exact same binutils sources built locally.

-- 
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/14675] No eh_frame info registered in exception_static_test

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=14675

--- Comment #5 from cvs-commit at gcc dot gnu.org  ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, hjl/pr14675 has been created
at  c694de32e282069ac0965ebb650cea7de4bf6a30 (commit)

- Log -
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c694de32e282069ac0965ebb650cea7de4bf6a30

commit c694de32e282069ac0965ebb650cea7de4bf6a30
Author: H.J. Lu 
Date:   Sat Dec 20 05:45:51 2014 -0800

Treat .eh_frame section before crtbeginT as normal input

Force the exception frame section from input files before the crtbeginT
file to be handled as an ordinary input section if we aren't creating
the exception frame header.  If we don't do this, we won't correctly
handle the special marker symbol in the exception frame section in the
crtbeginT file.

PR gold/14675
* ehframe.cc (Eh_frame::add_ehframe_input_section): Force the
exception frame section from input files if it can't be
optimized.
(Eh_frame::add_ehframe_input_section<32, false>): Updated.
(Eh_frame::add_ehframe_input_section<32, true>): Likewise.
(Eh_frame::add_ehframe_input_section<64, false>): Likewise.
(Eh_frame::add_ehframe_input_section<64, true>): Likewise.
* ehframe.h (Eh_frame::add_ehframe_input_section): Add a
bool parameter to indicate if the exception frame section
can be optimized.
* layout.cc (Layout::Layout): Initialize optimize_ehframe_ to
!has_crtbeginT.
(Layout::layout_eh_frame): Pass this->optimize_ehframe_ to
Eh_frame::add_ehframe_input_section.
(Layout::make_eh_frame_section): Set this->optimize_ehframe_
to true when processing the crtbeginT file if it is on command
line.
(Layout::match_file_name (const char*, const char*)): New.
(Layout::match_file_name(const Relobj*, const char*): Use it.
* layout.h (Layout::Layout): Add has_crtbeginT.
(Layout::match_file_name (const char*, const char*)): New.
(Layout): Add an optimize_ehframe_ member.
* main.cc (main): Pass command_line.has_crtbeginT() to layout.
* options.cc: Include "layout.h".
(Input_arguments::add_file): Set this->has_crtbeginT_ to true
if there is a crtbeginT file.
* options.h (Input_arguments::Input_arguments): Initialize
has_crtbeginT_ to false.
(Input_arguments::has_crtbeginT): New function.
(Input_arguments::has_crtbeginT_): New bool member.
(Command_line::has_crtbeginT): New function.

---

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