date:20130602

[Bug ld/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.

2013-06-02 Thread marxin.liska at gmail dot com

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



--- Comment #11 from Martin Liška  ---

So the bug is really present in binutils trunk (May 24 2013).



ld --version:

GNU ld (GNU Binutils) 2.23.52.20130524



gcc --version:

gcc (GCC) 4.9.0 20130517 (experimental)



Compilation error:

S=/home/marxin/Programming/libreoffice-lto-test && O=$S/solver/unxlngx6
.pro &&

W=$S/workdir/unxlngx6.pro &&  mkdir -p $W/LinkTarget/Executable/ && g++  
-flto

-fno-fat-lto-objects -fuse-linker-plugin -O2   -Wl,-z,origin

'-Wl,-rpath,$ORIGIN/../lib:$ORIGIN' -Wl,-rpath-link,$O/lib -Wl,-z,defs 

-Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -L$O/lib  -Wl,--hash-style
=gnu 

-Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo

-Wl,-Bsymbolic-functions  -Wl,-O1 -Wl,-S 

$W/CxxObject/i18npool/source/localedata/LocaleNode.o

$W/CxxObject/i18npool/source/localedata/filewriter.o

$W/CxxObject/i18npool/source/localedata/saxparser.o -Wl,--start-group
 

-Wl,--end-group -Wl,--no-as-needed   -luno_cppu -luno_cppuhelpergcc3 -luno_
sal

-o $W/LinkTarget/Executable/saxparser

/home/marxin/Programming/libreoffice-lto-test/workdir/unxlngx6.pro/CxxObjec
t/i18npool/source/localedata/saxparser.o

(symbol from plugin): undefined reference to `typeinfo for

com::sun::star::uno::Exception'

/home/marxin/Programming/libreoffice-lto-test/workdir/unxlngx6.pro/CxxObjec
t/i18npool/source/localedata/saxparser.o

(symbol from plugin): undefined reference to `typeinfo name for

com::sun::star::uno::RuntimeException'

/home/marxin/Programming/libreoffice-lto-test/workdir/unxlngx6.pro/CxxObjec
t/i18npool/source/localedata/saxparser.o

(symbol from plugin): undefined reference to `typeinfo for

com::sun::star::uno::RuntimeException'

/home/marxin/Programming/libreoffice-lto-test/workdir/unxlngx6.pro/CxxObjec
t/i18npool/source/localedata/saxparser.o

(symbol from plugin): undefined reference to `typeinfo name for

com::sun::star::uno::Exception'

collect2: error: ld returned 1 exit status



All 3 object files are added as an attachment.



Thanks,

Martin



-- 

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 ld/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.

2013-06-02 Thread marxin.liska at gmail dot com

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



--- Comment #12 from Martin Liška  ---

Created attachment 7054

  --> http://sourceware.org/bugzilla/attachment.cgi?id=7054&action=edit

Libreoffice saxparser object files



-- 

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 ld/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.

2013-06-02 Thread marxin.liska at gmail dot com

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



Martin Liška  changed:



   What|Removed |Added



 Status|RESOLVED|REOPENED

 Resolution|WORKSFORME  |---



--- Comment #13 from Martin Liška  ---

Test case was introduced.



-- 

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: Segfault in objdump?

2013-06-02 Thread Barret Rhoden

On 2013-06-02 at 14:23 Alan Modra wrote:
> On Sat, Jun 01, 2013 at 10:21:16AM -0700, Barret Rhoden wrote:
> > It does not fail if the Makefile doesn't
> > modify a file that it includes.
> 
> Doesn't this mean you have a make loop? 

AFAIK, make reads in the included file once, then attempts to update it
as a goal, sees it needs updated, and reincludes it since it knows it
has changed.  At that point, it is up to date, and doesn't re-touch it.

http://www.gnu.org/software/make/manual/make.html#Remaking-Makefiles

> I doubt that this objdump segfault is worth pursuing.

I can just avoid calling it with -S.  I was just wondering if anyone
would recognize the problem easily.  Thanks for reading.  =)

For those curious, the segfault is in
_bfd_stab_section_find_nearest_line().

Barret

-
Program received signal SIGSEGV, Segmentation fault.
0x2ac48acbabdf in _bfd_stab_section_find_nearest_line ()
from /usr/lib64/binutils/x86_64-pc-linux-gnu/2.23.1/libbfd-2.23.1.so
(gdb) bt 

#0  0x2ac48acbabdf in _bfd_stab_section_find_nearest_line
() from /usr/lib64/binutils/x86_64-pc-linux-gnu/2.23.1/libbfd-2.23.1.so

#1  0x2ac48acdf60b in _bfd_elf_find_nearest_line_discriminator ()
from /usr/lib64/binutils/x86_64-pc-linux-gnu/2.23.1/libbfd-2.23.1.so

#2  0x00408d85 in show_line () 
#3  0x004097ad in disassemble_section () 
#4  0x2ac48acba0ec in bfd_map_over_sections
() from /usr/lib64/binutils/x86_64-pc-linux-gnu/2.23.1/libbfd-2.23.1.so

#5  0x00405ff4 in disassemble_data () 
#6  0x0040827e in dump_bfd () 
#7  0x0040aaa0 in display_any_bfd () 
#8 0x0040ab60 in display_file.part.7 () 
#9 0x00405159 in main ()

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

Re: Segfault in objdump?

2013-06-02 Thread Alan Modra

On Sun, Jun 02, 2013 at 02:40:28PM -0700, Barret Rhoden wrote:
> On 2013-06-02 at 14:23 Alan Modra wrote:
> > On Sat, Jun 01, 2013 at 10:21:16AM -0700, Barret Rhoden wrote:
> > > It does not fail if the Makefile doesn't
> > > modify a file that it includes.
> > 
> > Doesn't this mean you have a make loop? 
> 
> AFAIK, make reads in the included file once, then attempts to update it
> as a goal, sees it needs updated, and reincludes it since it knows it
> has changed.  At that point, it is up to date, and doesn't re-touch it.
> 
> http://www.gnu.org/software/make/manual/make.html#Remaking-Makefiles

If I run make with your Makefile, it runs for varying amounts of time
before invoking objdump.  make -dm shows make re-execing itself many
times.  Quite clearly make is touching both olderfile and newerfile
many times.  I think you really do have an infinite loop, which for
some unknown reason terminates.  My hypothesis was some sort of
resource starvation, which then also causes the objdump problem.

On my x86_64-linux box (AMD FX-8120 8 core)
rm akaros-kernel.asm; make -dm > /tmp/dump 2>&1
ls -l /tmp/dump
-rw-r--r-- 1 alan alan 2055825637 Jun  2 22:00 /tmp/dump
grep Re-exec /tmp/dump | wc -l
54492

On a powerpc64-linux box (old mac G5) make seems to run forever.

-- 
Alan Modra
Australia Development Lab, IBM

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

Re: Segfault in objdump?

2013-06-02 Thread Barret Rhoden

> If I run make with your Makefile, it runs for varying amounts of time
> before invoking objdump.  make -dm shows make re-execing itself many
> times.  Quite clearly make is touching both olderfile and newerfile
> many times.  I think you really do have an infinite loop, which for
> some unknown reason terminates.  My hypothesis was some sort of
> resource starvation, which then also causes the objdump problem.

make -dm also seemed to take forever for me, and would re-run make for
a while.

Can you try again with these two lines in the makefile?

olderfile: ;
Makefile: ;

I noticed most of my make -d output was searching for implicit rules
for those two targets.  When I run make -dm with that modification,
make only runs twice, updating 'newerfile the first time, and then
segfaults:

$ make -dm
GNU Make 3.82
Built for x86_64-pc-linux-gnu
Copyright (C) 2010  Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
 This is free software: you are free
to change and redistribute it. There is NO WARRANTY, to the extent
permitted by law. Reading makefiles...
Reading makefile `Makefile'...
Reading makefile `newerfile' (search path) (no ~ expansion)...
Updating makefiles
 Considering target file `newerfile'.
   Considering target file `olderfile'.
Finished prerequisites of target file `olderfile'.
   No need to remake target `olderfile'.
  Finished prerequisites of target file `newerfile'.
  Prerequisite `olderfile' is newer than target `newerfile'.
 Must remake target `newerfile'.
Invoking recipe from Makefile:35 to update target `newerfile'.
Putting child 0x664e30 (newerfile) PID 23008 on the chain.
Live child 0x664e30 (newerfile) PID 23008 
Reaping winning child 0x664e30 PID 23008 
Removing child 0x664e30 PID 23008 from chain.
 Successfully remade target file `newerfile'.
 Considering target file `Makefile'.
  Finished prerequisites of target file `Makefile'.
 No need to remake target `Makefile'.
Re-executing[1]: make -dm
GNU Make 3.82
Built for x86_64-pc-linux-gnu
Copyright (C) 2010  Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
 This is free software: you are free
to change and redistribute it. There is NO WARRANTY, to the extent
permitted by law. Reading makefiles...
Reading makefile `Makefile'...
Reading makefile `newerfile' (search path) (no ~ expansion)...
Updating makefiles
 Considering target file `newerfile'.
   Considering target file `olderfile'.
Finished prerequisites of target file `olderfile'.
   No need to remake target `olderfile'.
  Finished prerequisites of target file `newerfile'.
  Prerequisite `olderfile' is older than target `newerfile'.
 No need to remake target `newerfile'.
 Considering target file `Makefile'.
  Finished prerequisites of target file `Makefile'.
 No need to remake target `Makefile'.
Updating goal targets
Considering target file `source'.
 File `source' does not exist.
 Finished prerequisites of target file `source'.
Must remake target `source'.
Invoking recipe from Makefile:25 to update target `source'.
objdump -S akaros-kernel > akaros-kernel.asm
Putting child 0x13b8ab0 (source) PID 23010 on the chain.
Live child 0x13b8ab0 (source) PID 23010 
/bin/sh: line 1: 23011 Segmentation fault  objdump -S akaros-kernel
> akaros-kernel.asm Reaping losing child 0x13b8ab0 PID 23010 
make: *** [source] Error 139
Removing child 0x13b8ab0 PID 23010 from chain.


Thanks,

Barret



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

[Bug ld/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.

2013-06-02 Thread amodra at gmail dot com

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

--- Comment #14 from Alan Modra  ---
I suspect you're picking up some older ld.  Note addition of -Wl,-v to show
versions in the following:

alan@bubble:~/build/libreoffice$ B=/home/alan/build/libreoffice &&
O=$B/solver/unxlngx6.pro && W=$B/workdir/unxlngx6.pro &&  mkdir -p
$W/LinkTarget/Executable/ && g++ -flto -fno-fat-lto-objects -fuse-linker-plugin
-O2 -Wl,-z,origin '-Wl,-rpath,$ORIGIN/../lib:$ORIGIN' -Wl,-rpath-link,$O/lib
-Wl,-z,defs -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -L$O/lib
-Wl,--hash-style=gnu -Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo
-Wl,-Bsymbolic-functions -Wl,-O1 -Wl,-S
$B/libreoffice-object-files/LocaleNode.o
$B/libreoffice-object-files/filewriter.o
$B/libreoffice-object-files/saxparser.o -Wl,--start-group -Wl,--end-group
-Wl,--no-as-needed -luno_cppu -luno_cppuhelpergcc3 -luno_sal -o
$W/LinkTarget/Executable/saxparser -Wl,-v
collect2 version 4.9.0 20130522 (experimental)
/usr/local/lib/gcc/x86_64-linux/4.9.0/../../../../x86_64-linux/bin/ld -plugin
/usr/local/libexec/gcc/x86_64-linux/4.9.0/liblto_plugin.so
-plugin-opt=/usr/local/libexec/gcc/x86_64-linux/4.9.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccbxEkZk.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
/home/alan/build/libreoffice/workdir/unxlngx6.pro/LinkTarget/Executable/saxparser
/usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o
/usr/local/lib/gcc/x86_64-linux/4.9.0/crtbegin.o
-L/home/alan/build/libreoffice/solver/unxlngx6.pro/lib
-L/usr/local/lib/gcc/x86_64-linux/4.9.0
-L/usr/local/lib/gcc/x86_64-linux/4.9.0/../../../../lib64
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/usr/local/lib/gcc/x86_64-linux/4.9.0/../../../../x86_64-linux/lib
-L/usr/local/lib/gcc/x86_64-linux/4.9.0/../../.. -z origin -rpath
$ORIGIN/../lib:$ORIGIN -rpath-link
/home/alan/build/libreoffice/solver/unxlngx6.pro/lib -z defs -rpath-link
/lib:/usr/lib -z combreloc --hash-style=gnu --dynamic-list-cpp-new
--dynamic-list-cpp-typeinfo -Bsymbolic-functions -O1 -S
/home/alan/build/libreoffice/libreoffice-object-files/LocaleNode.o
/home/alan/build/libreoffice/libreoffice-object-files/filewriter.o
/home/alan/build/libreoffice/libreoffice-object-files/saxparser.o --start-group
--end-group --no-as-needed -luno_cppu -luno_cppuhelpergcc3 -luno_sal -v
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/local/lib/gcc/x86_64-linux/4.9.0/crtend.o /usr/lib/x86_64-linux-gnu/crtn.o
GNU ld (GNU Binutils) 2.23.52.20130524
alan@bubble:~/build/libreoffice$ 

The other possibility is that my shared libraries are masking the problem
somehow.  If you are running the version of ld you think you are, please attach
the following shared libs:
-luno_cppu
(/home/alan/build/libreoffice/solver/unxlngx6.pro/lib/libuno_cppu.so)
-luno_cppuhelpergcc3
(/home/alan/build/libreoffice/solver/unxlngx6.pro/lib/libuno_cppuhelpergcc3.so)
-luno_sal (/home/alan/build/libreoffice/solver/unxlngx6.pro/lib/libuno_sal.so)

-- 
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: Segfault in objdump?

2013-06-02 Thread Alan Modra

On Sun, Jun 02, 2013 at 04:29:55PM -0700, Barret Rhoden wrote:
> > If I run make with your Makefile, it runs for varying amounts of time
> > before invoking objdump.  make -dm shows make re-execing itself many
> > times.  Quite clearly make is touching both olderfile and newerfile
> > many times.  I think you really do have an infinite loop, which for
> > some unknown reason terminates.  My hypothesis was some sort of
> > resource starvation, which then also causes the objdump problem.
> 
> make -dm also seemed to take forever for me, and would re-run make for
> a while.
> 
> Can you try again with these two lines in the makefile?
> 
> olderfile: ;
> Makefile: ;
> 
> I noticed most of my make -d output was searching for implicit rules
> for those two targets.  When I run make -dm with that modification,
> make only runs twice, updating 'newerfile the first time, and then
> segfaults:

I still see random numbers of make re-exec.  Here's the tail from one
run

Re-executing[945]: make -dm
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for x86_64-pc-linux-gnu
Reading makefiles...
Reading makefile `Makefile'...
Reading makefile `newerfile' (search path) (no ~ expansion)...
Updating makefiles
 Considering target file `newerfile'.
   Considering target file `olderfile'.
Finished prerequisites of target file `olderfile'.
   No need to remake target `olderfile'.
  Finished prerequisites of target file `newerfile'.
  Prerequisite `olderfile' is newer than target `newerfile'.
 Must remake target `newerfile'.
Putting child 0x00e1a100 (newerfile) PID 23692 on the chain.
Live child 0x00e1a100 (newerfile) PID 23692 
Reaping winning child 0x00e1a100 PID 23692 
Removing child 0x00e1a100 PID 23692 from chain.
 Successfully remade target file `newerfile'.
 Considering target file `Makefile'.
  Finished prerequisites of target file `Makefile'.
 No need to remake target `Makefile'.
Re-executing[946]: make -dm
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for x86_64-pc-linux-gnu
Reading makefiles...
Reading makefile `Makefile'...
Reading makefile `newerfile' (search path) (no ~ expansion)...
Updating makefiles
 Considering target file `newerfile'.
   Considering target file `olderfile'.
Finished prerequisites of target file `olderfile'.
   No need to remake target `olderfile'.
  Finished prerequisites of target file `newerfile'.
  Prerequisite `olderfile' is older than target `newerfile'.
 No need to remake target `newerfile'.
 Considering target file `Makefile'.
  Finished prerequisites of target file `Makefile'.
 No need to remake target `Makefile'.
Updating goal targets
Considering target file `source'.
 File `source' does not exist.
 Finished prerequisites of target file `source'.
Must remake target `source'.
objdump -S akaros-kernel > akaros-kernel.asm
Putting child 0x011480e0 (source) PID 23694 on the chain.
Live child 0x011480e0 (source) PID 23694 
Segmentation fault (core dumped)
Reaping losing child 0x011480e0 PID 23694 
make: *** [source] Error 139
Removing child 0x011480e0 PID 23694 from chain.

-- 
Alan Modra
Australia Development Lab, IBM

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

Re: Segfault in objdump?

2013-06-02 Thread Alan Modra

Curiousity got the better of me.  The problem is triggered by
a) Different memory layout when running objdump -S under make
b) Trailing rubbish at the end of your .stab section
 c01f75c8  44001801 e6a013c0   D...
 c01f75d8 44001901 e8a013c0  44001a01  D...D...
 c01f75e8 e9a013c0 ..  
   
c) These zeros are seen as a marker for the next compilation unit
   (see include/aout/stab.def N_UNDF), bumping the .stabstr offset
   (bdf/syms.c:1158).
d) syms.c:1178 and syms.c:1247 store this offset string pointer with
   a pointer to a previous stab.

We ought to be keeping a copy of the string pointer for use with any
previous stab.

* syms.c (_bfd_stab_section_find_nearest_line): Add last_str
var.  Use it with last_stab.

Index: bfd/syms.c
===
RCS file: /cvs/src/src/bfd/syms.c,v
retrieving revision 1.58
diff -u -p -r1.58 syms.c
--- bfd/syms.c  10 Jan 2013 20:03:55 -  1.58
+++ bfd/syms.c  3 Jun 2013 04:01:18 -
@@ -934,7 +934,7 @@ _bfd_stab_section_find_nearest_line (bfd
   struct stab_find_info *info;
   bfd_size_type stabsize, strsize;
   bfd_byte *stab, *str;
-  bfd_byte *last_stab = NULL;
+  bfd_byte *last_stab, *last_str;
   bfd_size_type stroff;
   struct indexentry *indexentry;
   char *file_name;
@@ -1147,8 +1147,9 @@ _bfd_stab_section_find_nearest_line (bfd
   file_name = NULL;
   directory_name = NULL;
   saw_fun = 1;
+  stroff = 0;
 
-  for (i = 0, stroff = 0, stab = info->stabs, str = info->strs;
+  for (i = 0, last_stab = stab = info->stabs, last_str = str = info->strs;
   i < info->indextablesize && stab < info->stabs + stabsize;
   stab += STABSIZE)
{
@@ -1174,7 +1175,7 @@ _bfd_stab_section_find_nearest_line (bfd
{
  info->indextable[i].val = bfd_get_32 (abfd, last_stab + 
VALOFF);
  info->indextable[i].stab = last_stab;
- info->indextable[i].str = str;
+ info->indextable[i].str = last_str;
  info->indextable[i].directory_name = directory_name;
  info->indextable[i].file_name = file_name;
  info->indextable[i].function_name = NULL;
@@ -1192,6 +1193,7 @@ _bfd_stab_section_find_nearest_line (bfd
  else
{
  last_stab = stab;
+ last_str = str;
  if (stab + STABSIZE >= info->stabs + stabsize
  || *(stab + STABSIZE + TYPEOFF) != (bfd_byte) N_SO)
{
@@ -1242,7 +1244,7 @@ _bfd_stab_section_find_nearest_line (bfd
{
  info->indextable[i].val = bfd_get_32 (abfd, last_stab + VALOFF);
  info->indextable[i].stab = last_stab;
- info->indextable[i].str = str;
+ info->indextable[i].str = last_str;
  info->indextable[i].directory_name = directory_name;
  info->indextable[i].file_name = file_name;
  info->indextable[i].function_name = NULL;

-- 
Alan Modra
Australia Development Lab, IBM

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

[Bug gas/15557] PowerPC: complex expressions before @l can give eror

2013-06-02 Thread super.lzh at gmail dot com

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

--- Comment #4 from super.lzh at gmail dot com ---
(In reply to Alan Modra from comment #3)
> http://sourceware.org/ml/binutils/2013-05/msg00072.html
> http://sourceware.org/ml/binutils/2013-05/msg00103.html

Thanks.

-- 
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 ld/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.

[Bug ld/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.

[Bug ld/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.

Re: Segfault in objdump?

Re: Segfault in objdump?

Re: Segfault in objdump?

[Bug ld/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.

Re: Segfault in objdump?

Re: Segfault in objdump?

[Bug gas/15557] PowerPC: complex expressions before @l can give eror

10 matches

Site Navigation

Mail list logo

Footer information