[Bug ld/16761] New: [PATCH] fix parallel make for cygwin/mingw target
https://sourceware.org/bugzilla/show_bug.cgi?id=16761 Bug ID: 16761 Summary: [PATCH] fix parallel make for cygwin/mingw target Product: binutils Version: 2.25 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: nickc at redhat dot com Reporter: yselkowitz at cygwin dot com Created attachment 7493 --> https://sourceware.org/bugzilla/attachment.cgi?id=7493&action=edit patch for binutils-gdb.git master Now that ld/Makefile.am calls WINDRES_FOR_TARGET in the new default-manifest.o rule, we must assure that all-binutils is built before all-ld; this actually failed consistently for me at -j3 on an F20 VM. Patch attached. -- 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/16790] New: [cygwin|mingw] ld -v creates a.exe
https://sourceware.org/bugzilla/show_bug.cgi?id=16790 Bug ID: 16790 Summary: [cygwin|mingw] ld -v creates a.exe Product: binutils Version: 2.25 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: nickc at redhat dot com Reporter: yselkowitz at cygwin dot com Nick, A possibly unforeseen side-effect has resulted from the addition of default-manifest support for PE targets. Usually, a simple '[$target-]ld -v' only prints the version, and '[$target-]ld --verbose' without any other arguments prints the linker script but does not create a file. However, with the new Cygwin binutils (20140326 snapshot), an a.exe file is created in both cases. I presume this was not intentional. Could the previous behaviour be restored (IOW do not include default-manifest.o if there is nothing else to link)? -- 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/16790] [cygwin|mingw] ld -v creates a.exe
https://sourceware.org/bugzilla/show_bug.cgi?id=16790
Cygwin/X maintainer changed:
What|Removed |Added
CC||corinna at vinschen dot de,
||jon_y at users dot
sourceforge.net
--- Comment #3 from Cygwin/X maintainer ---
(In reply to Nick Clifton from comment #2)
> I have uploaded a potential fix for the problem. Please give it a try.
Thanks. That works for the usual use cases, but doesn't fix the (admittedly
odd but seemingly allowed) possibility of ld -v --verbose.
> I am uncertain as to whether this is the right thing to do however. Maybe
> it would be better to rethink the whole
> linker-is-responsible-for-adding-the-default-manifest idea. IMHO it would
> be better if gcc/libgcc did this - after all it already has the multilib
> mechanism in place and it already builds files like crt0.o and crtend.o.
> Why not add default-manifest.o to the list ? The answer, as I understand
> it, is that the cygwin developers want the manifest added even if gcc is not
> used to link the application. So maybe it is time to impose a requirement
> to use gcc to link all cygwin and mingw binaries ?
IIUC you are suggesting moving default-manifest.{rc,o} over to gcc, and adding
default-manifest.o to ENDFILE_SPEC in gcc/config/i386/cygwin.h and
gcc/config/i386/mingw32.h (mingw-w64 is covered by the latter wrt
ENDFILE_SPEC). While most of the support work did have to go into ld, there
doesn't seem to be much precedent for this last step of ld adding object files
on its own. Would anything have to be changed in pe{,p}.sc to continue to
avoid duplicate manifests if default-manifest.o is being passed with every link
(whether there is already a manifest or not)?
If that's not an issue, I think the main question would be one of deployment.
As it's probably too late to get this into upstream GCC for 4.9.0; would 4.9.1
be a possibility, or would it end up sitting in trunk for a year or more until
4.10.0? Until it's in a released and shipped version, it would be up to
vendors to maintain a patch. For cygwin that's easy to assure, but there are a
lot of different vendors of mingw.org and/or mingw-w64 compilers.
The only other technical issue with that would be clang; last I checked (it's
been a while), it was still handing off to gcc for linking on PE platforms, but
if that has or will ever be changed to match the behaviour for (at least) linux
targets to link with ld, then it too would have to be patched. This doesn't
mean that the burden of adding default-manifest.o must fall to binutils, but it
should be noted.
AFAIK nothing else links directly with ld for Cygwin; anything that tried would
likely be wrong anyway. I imagine the same would be true for mingw*, but I
can't say for sure.
I'm CC'ing Corinna and JonY for their thoughts on this.
--
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/16807] Bad behavior with resources of Windows applications with recent binutils upgrade on Cygwin64
https://sourceware.org/bugzilla/show_bug.cgi?id=16807 Cygwin/X maintainer changed: What|Removed |Added CC||yselkowitz at cygwin dot com Component|binutils|ld Version|2.24|2.25 (HEAD) Assignee|unassigned at sourceware dot org |nickc at redhat dot com -- 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/16821] x86_64 PE/COFF: ld truncates addresses of symbols from linker scripts to 32 bit
https://sourceware.org/bugzilla/show_bug.cgi?id=16821 Cygwin/X maintainer changed: What|Removed |Added CC||yselkowitz at cygwin dot com -- 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/16792] $tooldir/lib is sysrooted when built --with-sysroot
https://sourceware.org/bugzilla/show_bug.cgi?id=16792 --- Comment #2 from Cygwin/X maintainer --- When a sysroot is in use, libraries usually end up in =/lib and =/usr/lib (or =/mingw/lib for *-*-mingw*), but $exec_prefix/$target_alias/lib has still been scanned. Not only is that not happening at the moment, but sysrooting that directory really doesn't make sense. -- 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 gas/17753] New: mep-elf gas SEGVs
https://sourceware.org/bugzilla/show_bug.cgi?id=17753
Bug ID: 17753
Summary: mep-elf gas SEGVs
Product: binutils
Version: 2.25
Status: NEW
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: yselkowitz at cygwin dot com
Host: x86_64-cygwin
Target: mep-elf
Build: x86_64-cygwin
Created attachment 8023
--> https://sourceware.org/bugzilla/attachment.cgi?id=8023&action=edit
result of mep-elf gcc/xgcc -B gcc -S on "int main(void){return 0;}"
mep-elf gas from binutils 2.25 is failing to compile the simplest assembly;
simple test case attached.
$ gdb --args
../cross-binutils/cross-binutils-2.25-1.x86_64/build/mep-elf/gas/.libs/as-new
mep-ret0.s
GNU gdb (GDB) 7.8
[snip]
Reading symbols from mep-elf/gas/.libs/as-new...done.
(gdb) r
Starting program: mep-elf/gas/.libs/as-new mep-ret0.s
[New Thread 15824.0x27bc]
[New Thread 15824.0x3a54]
Program received signal SIGSEGV, Segmentation fault.
cgen_bitset_copy (mask=mask@entry=0x1)
opcodes/cgen-bitset.c:152
152 newmask = cgen_bitset_create ((mask->length * 8) - 1);
(gdb) bt
#0 cgen_bitset_copy (mask=mask@entry=0x1)
at opcodes/cgen-bitset.c:152
#1 0x00010042e862 in mep_cgen_cpu_open (arg_type=,
arg_type@entry=CGEN_CPU_OPEN_MACHS)
at opcodes/mep-desc.c:6317
#2 0x000100424ee5 in md_begin ()
at gas/config/tc-mep.c:489
#3 0x00010049fa41 in perform_an_assembly_pass (argv=0x60003aa90, argc=2)
at gas/as.c:1082
#4 main (argc=2, argv=0x60003aa90)
at gas/as.c:1226
--
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 gas/17753] mep-elf gas SEGVs
https://sourceware.org/bugzilla/show_bug.cgi?id=17753
--- Comment #2 from Cygwin/X maintainer ---
(In reply to Alan Modra from comment #1)
> I don't see the failure here. Are you picking up the wrong libopcodes.so?
I built this with static libbfd/libopcodes. However, now that you mention it,
I confirmed that it does not happen on Linux, which gave me a clue as to what
to look for.
In opcodes/mep-desc.c:mep_cgen_cpu_open() there is the following:
va_start (ap, arg_type);
while (arg_type != CGEN_CPU_OPEN_END)
{
switch (arg_type)
{
case CGEN_CPU_OPEN_ISAS :
isas = va_arg (ap, CGEN_BITSET *); <===
break;
case CGEN_CPU_OPEN_MACHS :
machs = va_arg (ap, unsigned int);
break;
But in gas/config/tc-mep.c:md_begin():
/* Set the machine number and endian. */
gas_cgen_cpu_desc = mep_cgen_cpu_open (CGEN_CPU_OPEN_MACHS, 0,
CGEN_CPU_OPEN_ENDIAN,
target_big_endian
? CGEN_ENDIAN_BIG
: CGEN_ENDIAN_LITTLE,
CGEN_CPU_OPEN_ISAS, 0, <===
CGEN_CPU_OPEN_END);
Because of the differences in MS Win64 ABI vs SysV ABI[1], this '0' doesn't get
handled the same way on Cygwin (or presumably on MinGW64) as it does on Linux,
and it results in picking up garbage from the stack (IIUC). Being specific
with the varargs types here, particularly that one, seems to fix it.
[1]
https://sourceforge.net/p/mingw-w64/wiki2/MinGW%20x64%20Software%20convention/
--
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 gas/17753] mep-elf gas SEGVs
https://sourceware.org/bugzilla/show_bug.cgi?id=17753 --- Comment #3 from Cygwin/X maintainer --- Created attachment 8024 --> https://sourceware.org/bugzilla/attachment.cgi?id=8024&action=edit Proposed patch Please consider this patch for master and the 2.25 branch. -- 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 gas/17754] New: Buffer overflow detected in MinGW gas
https://sourceware.org/bugzilla/show_bug.cgi?id=17754
Bug ID: 17754
Summary: Buffer overflow detected in MinGW gas
Product: binutils
Version: 2.25
Status: NEW
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: yselkowitz at cygwin dot com
CC: ktietz at redhat dot com, nickc at redhat dot com
Host: x86_64-redhat-linux (RHEL/CentOS 6)
Target: {i686,x86_64}-w64-mingw32
Build: x86_64-redhat-linux (RHEL/CentOS 6)
With 2.25 on EL6 x86_64 host, {i686,x86_64}-w64-mingw32 target, a buffer
overflow is detected when compiling even the simplest assembly:
$ gdb /usr/i686-w64-mingw32/bin/as
[snip]
Reading symbols from /usr/i686-w64-mingw32/bin/as...Reading symbols from
/usr/lib/debug/usr/i686-w64-mingw32/bin/as.debug...done.
done.
(gdb) r -v -o test.o test.s
Starting program: /usr/i686-w64-mingw32/bin/as -v -o test.o test.s
GNU assembler version 2.25 (i686-w64-mingw32) using BFD version (GNU Binutils)
2.25
*** buffer overflow detected ***: /usr/i686-w64-mingw32/bin/as terminated
=== Backtrace: =
/lib64/libc.so.6(__fortify_fail+0x37)[0x77731697]
/lib64/libc.so.6(+0x100580)[0x7772f580]
/lib64/libc.so.6(__strncpy_chk+0x17b)[0x7772e84b]
/usr/i686-w64-mingw32/bin/as[0x43fbf4]
/usr/i686-w64-mingw32/bin/as[0x44018e]
/usr/i686-w64-mingw32/bin/as[0x45845b]
/usr/i686-w64-mingw32/bin/as[0x4436a1]
/usr/i686-w64-mingw32/bin/as[0x416af3]
/usr/i686-w64-mingw32/bin/as[0x405370]
/usr/i686-w64-mingw32/bin/as[0x4b5767]
/usr/i686-w64-mingw32/bin/as[0x4b5816]
/usr/i686-w64-mingw32/bin/as[0x40506c]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7764dd5d]
/usr/i686-w64-mingw32/bin/as[0x4029e9]
=== Memory map:
0040-00576000 r-xp fd:00 532449
/usr/i686-w64-mingw32/bin/as
00776000-00779000 rw-p 00176000 fd:00 532449
/usr/i686-w64-mingw32/bin/as
00779000-007e9000 rw-p 00:00 0 [heap]
71384000-7139a000 r-xp fd:00 654082
/lib64/libgcc_s-4.4.7-20120601.so.1
7139a000-71599000 ---p 00016000 fd:00 654082
/lib64/libgcc_s-4.4.7-20120601.so.1
71599000-7159a000 rw-p 00015000 fd:00 654082
/lib64/libgcc_s-4.4.7-20120601.so.1
7159a000-7179e000 rw-p 00:00 0
7179e000-7762f000 r--p fd:00 393971
/usr/lib/locale/locale-archive
7762f000-777b9000 r-xp fd:00 656988
/lib64/libc-2.12.so
777b9000-779b9000 ---p 0018a000 fd:00 656988
/lib64/libc-2.12.so
779b9000-779bd000 r--p 0018a000 fd:00 656988
/lib64/libc-2.12.so
779bd000-779be000 rw-p 0018e000 fd:00 656988
/lib64/libc-2.12.so
779be000-779c3000 rw-p 00:00 0
779c3000-779c5000 r-xp fd:00 656994
/lib64/libdl-2.12.so
779c5000-77bc5000 ---p 2000 fd:00 656994
/lib64/libdl-2.12.so
77bc5000-77bc6000 r--p 2000 fd:00 656994
/lib64/libdl-2.12.so
77bc6000-77bc7000 rw-p 3000 fd:00 656994
/lib64/libdl-2.12.so
77bc7000-77bdc000 r-xp fd:00 657068
/lib64/libz.so.1.2.3
77bdc000-77ddb000 ---p 00015000 fd:00 657068
/lib64/libz.so.1.2.3
77ddb000-77ddc000 r--p 00014000 fd:00 657068
/lib64/libz.so.1.2.3
77ddc000-77ddd000 rw-p 00015000 fd:00 657068
/lib64/libz.so.1.2.3
77ddd000-77dfd000 r-xp fd:00 656981
/lib64/ld-2.12.so
77e65000-77feb000 rw-p 00:00 0
77ff8000-77ffb000 rw-p 00:00 0
77ffb000-77ffc000 r-xp 00:00 0 [vdso]
77ffc000-77ffd000 r--p 0001f000 fd:00 656981
/lib64/ld-2.12.so
77ffd000-77ffe000 rw-p 0002 fd:00 656981
/lib64/ld-2.12.so
77ffe000-77fff000 rw-p 00:00 0
7ffea000-7000 rw-p 00:00 0
[stack]
ff60-ff601000 r-xp 00:00 0
[vsyscall]
Program received signal SIGABRT, Aborted.
0x77661625 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6.x86_64
libgcc-4.4.7-11.el6.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0 0x77661625 in raise () from /lib64/libc.so.6
#1 0x77662e05 in abort () from /lib64/libc.so.6
#2 0x7769f537 in __libc_message () from /lib64/libc.so.6
#3 0x77731697 in __fortify_fail () from /lib64/libc.so.6
#4 0x7772f580 in __chk_fail () from /lib64/libc.so.6
#5
[Bug binutils/17755] New: sh64-elf SEGV when stripping libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=17755 Bug ID: 17755 Summary: sh64-elf SEGV when stripping libraries Product: binutils Version: 2.25 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: yselkowitz at cygwin dot com Host: x86_64-cygwin, x86_64-redhat-linux Target: sh64-elf Build: x86_64-cygwin, x86_64-redhat-linux 1) Build binutils-2.25 with --target=sh64-elf and install 2) Build gcc-4.9.2 with --target=sh64-elf --without-headers 3) 'sh64-elf-strip -g' the generated libgcc*.a SEGVs (but doing so to the crt*.o works): $ gdb --args .../sh64-elf/binutils/.libs/strip-new.exe -g .../lib/gcc/sh64-elf/4.9.2/m5-64media/libgcc-4-300.a [snip] Reading symbols from .../sh64-elf/binutils/.libs/strip-new.exe...done. (gdb) r Starting program: .../sh64-elf/binutils/.libs/strip-new.exe -g .../lib/gcc/sh64-elf/4.9.2/m5-64media/libgcc-4-300.a [New Thread 13728.0x42d0] [New Thread 13728.0x434c] Program received signal SIGSEGV, Segmentation fault. sh_elf64_copy_private_data_internal (ibfd=0x6000505a0, obfd=0x600055b30) at .../binutils-2.25/bfd/elf64-sh64.c:2281 2281o_shdrp[oIndex]->sh_flags |= SHF_SH5_ISA32; (gdb) bt #0 sh_elf64_copy_private_data_internal (ibfd=0x6000505a0, obfd=0x600055b30) at .../binutils-2.25/bfd/elf64-sh64.c:2281 #1 0x000100403d04 in copy_object (ibfd=ibfd@entry=0x6000505a0, obfd=obfd@entry=0x600055b30, input_arch=input_arch@entry=0x0) at .../binutils-2.25/binutils/objcopy.c:2211 #2 0x0001004041e1 in copy_archive (ibfd=, obfd=, output_target=, force_output_target=, input_arch=0x0) at .../binutils-2.25/binutils/objcopy.c:2369 #3 0x000100404830 in copy_file (input_filename=, output_filename=output_filename@entry=0x60003ac40 ".../lib/gcc/sh64-elf/4.9.2/m5-64media/stX8sIQK", input_target=input_target@entry=0x0, output_target=0x1004e5ea8 "elf64-sh64", output_target@entry=0x0, input_arch=input_arch@entry=0x0) at .../binutils-2.25/binutils/objcopy.c:2530 #4 0x0001004ab450 in strip_main (argv=, argc=) at .../binutils-2.25/binutils/objcopy.c:3399 #5 main (argc=3, argv=0xc2ca80) at .../binutils-2.25/binutils/objcopy.c:4403 -- 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/6744] --export-dynamic does nothing for Cygwin .exe's
-- What|Removed |Added Version|2.19|2.20 (HEAD) http://sourceware.org/bugzilla/show_bug.cgi?id=6744 --- 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/6744] --export-dynamic does nothing for Cygwin .exe's
--- Additional Comments From yselkowitz at cygwin dot com 2009-03-24 02:02 --- (In reply to comment #2) > --export-dynamic is an ELF format option, and --export-all-symbols is the PE > equivalent. Dave, thanks for looking at this. The ld texinfo docs say nothing about --export-dynamic being ELF-specific, so if this is indeed the case, that should be made clear. > We could reasonably make --export-dynamic a synonym for PE, I expect. Sounds like a good idea. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6744 --- 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/6744] --export-dynamic does nothing for Cygwin .exe's
--- Additional Comments From yselkowitz at cygwin dot com 2009-03-24 06:45 --- > It would certainly be technically correct if libtool chose to use --e-a-s > rather than --e-d when linking for a cygwin target, since it's the target- > specific equivalent. Good point, changing libtool would cover most, but not all, of the cases. > Why not post an RFC on the binutils list asking if anyone can see a downside > of making --e-d a synonym for --e-a-s? I don't follow the binutils list nowadays. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6744 --- 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/6744] --export-dynamic does nothing for Cygwin .exe's
--- Additional Comments From yselkowitz at cygwin dot com 2009-04-01 16:18 --- Chuck has pushed the corresponding libtool patch upstream, so this should handle many cases where it would be used. I suppose a warning would be appropriate, as would clarification in the documentation on this flag. -- What|Removed |Added Status|WAITING |NEW http://sourceware.org/bugzilla/show_bug.cgi?id=6744 --- 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/6744] --export-dynamic does nothing for Cygwin .exe's
--- Additional Comments From yselkowitz at cygwin dot com 2009-04-02 03:45 --- (In reply to comment #9) > It also mentions --e-a-s in the --export-dynamic documentation. "PE targets support a similar function to export all symbols from a DLL;" or EXE, which is actually what I'm more concerned about here. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6744 --- 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
