X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com Message-ID: <55703CF2.5030900@gmx.de> Date: Thu, 04 Jun 2015 13:56:34 +0200 From: "Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de)" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.13) Gecko/20101206 SUSE/3.1.7 Thunderbird/3.1.7 MIME-Version: 1.0 To: bug-binutils AT gnu DOT org CC: djgpp AT delorie DOT com Subject: DJGPP port of binutils broken due to 64 bit cygwin fix. Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:EMZWi65SOffMWmR6f0w6stDsqEBAw/4sJ5SdM9H38jag1k78cbC DwBCRg08BjZY//ZhcgGMnlev+te6MprvrKFMLDf7QRYwazJJtx1SPN/77TMyW5nUy8et3yB ltjQPx5OhLLjnjFfPxDFWT1IHPRU8tk0St9nnxt7Nu6GAfeNlhojfPGxGf24qPG9uo4DZa9 tAKVNXrQFJKR6uX+5Ss9A== X-UI-Out-Filterresults: notjunk:1;V01:K0:22CLlC23tes=:Q3TNnVUgXbik8eHO3l2faE /+IzGNjNuiifYNeqAQZDrPBwF4tRidJQN11hRXxOyRfMR4Igw6I/NcMyoh4TXAg05ueBPmNOV In7UDSmJ+w06YihZJqwK7KQhDlS7Vr1KSXCwfcO4tyyZUbBZAJEl3VnZXmZ4vVuhKc0KgcVWK 44ju6PZvfKnw1/Bbktmv/gU+SMoPvrFmMrbiGFKWkaas2scWSX8MNfl3Noz5lcl4CeF9CuefN 0bcZPWCmtBymvy+05PZ2bz0xmX1SaG5P4GBRLDGWTg6B3WC4wGuGLVfEFL/SOL19BethPNC2C umNC7MkQQNE10sGZij4KPNleBu2sK1SIJRqoE2YChaQvB5P5uMpB8NUHtbkBuOefysFvOw2+6 5LmeOFEgi9ZIxPqApw63fB2dvZgu/iTQnaBk/maXKzHt/BYE9PmdZRYri0w+EKGOc6a0kSYw2 k7rl452gWxkzFSNYgAb5VNpxOQH/eNs37ujhd9SmbinFzZUm70fAH8jgeUlmco0887a5Q9g42 oYBFIhmRs1qBL34xxLg20C5PL/Z+b8v63Y+6XE5a+K6QUtz9d6vnJ/XczbJCWluRU1b0LZqO4 X4ofDJC7X9axm5pwCwedByink6cICe9kjOStde6c6ox7olV1Sd7FmROf0zX9pGFLNoeW/pjbD feqdSCDiOYghBeLMoRrDL1sg3VekMZURCCdvAbLHaWgRRvhAhqFLeCh9lvB2nsPjR6lU= Reply-To: djgpp AT delorie DOT com It turns out that the DJGPP (aka go32) port of binutils has been broken since binutils 2.25 has been released. The DJGPP port of binutils 2.24 and previous versions works flawlessly. Please note that there is nothing particular about this port. It is simply an absolute generic 32-bit coff system that uses DWARF2. The breakage can be demonstrated by compiling a simple hello-world program with the flags -g2 -O0. If one tries to step through the code using the DJGPP port of gdb then the following output will be displayed: ----------------------- start of gdb output ------------------------------- C:\tmp\5>gdb a.exe GNU gdb (GDB) 7.7.1 Copyright (C) 2014 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. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i786-pc-msdosdjgpp --target=djgpp". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from a.exe...done. (gdb) b main Breakpoint 1 at 0x1f6a (gdb) r Starting program: c:/tmp/5/a.exe Breakpoint 1, 0x00001f6a in main () (gdb) s Single stepping until exit from function main, which has no line number information. hello world 0x00004504 in __crt1_startup () (gdb) ----------------------- end of gdb output ------------------------------- If one uses objdump to inspect the binary, using --dwarf, an output like this will be produced: ----------------------- start of objdump output ------------------------------- a.exe: file format coff-go32-exe Contents of the .debug_aranges section: C:\DJGPP-2.04\BIN/objdump.exe: Warning: Bogus end-of-siblings marker detected at offset b1 in .debug_info section C:\DJGPP-2.04\BIN/objdump.exe: Warning: Bogus end-of-siblings marker detected at offset b2 in .debug_info section C:\DJGPP-2.04\BIN/objdump.exe: Warning: DIE at offset b3 refers to abbreviation number 3986 which does not exist Length: 28 Version: 2 Offset into .debug_info: 0x0 Pointer Size: 4 Segment Size: 0 [snip, truncated by me] Contents of the .debug_info section: Compilation Unit @ offset 0x0: Length: 0x46 (32-bit) Version: 2 Abbrev Offset: 0x0 Pointer Size: 4 <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : 0x0 <10> DW_AT_low_pc : 0x1a10 <14> DW_AT_high_pc : 0x1f27 <18> DW_AT_name : crt0.S <1f> DW_AT_comp_dir : c:/djgpp-O0-g2/src/libc/crt0 <3c> DW_AT_producer : GNU AS 2.25 <48> DW_AT_language : 32769 (MIPS assembler) Compilation Unit @ offset 0x4a: Length: 0x19f (32-bit) Version: 2 Abbrev Offset: 0x0 Pointer Size: 4 <0><55>: Abbrev Number: 1 (DW_TAG_compile_unit) <56> DW_AT_stmt_list : 0x20554e47 <5a> DW_AT_low_pc : 0x2e342043 <5e> DW_AT_high_pc : 0x20322e39 <62> DW_AT_name : -fpreprocessed -mtune=pentium -march=pentium -g3 -gdwarf-2 -O0 DW_AT_comp_dir : a.c DW_AT_producer : c:/tmp/5 DW_AT_language : 7984 (Unknown: 1f30) <0>: Abbrev Number: 0 C:\DJGPP-2.04\BIN/objdump.exe: Warning: Bogus end-of-siblings marker detected at offset b1 in .debug_info section C:\DJGPP-2.04\BIN/objdump.exe: Warning: Further warnings about bogus end-of-sibling markers suppressed <-1>: Abbrev Number: 0 <-2>: Abbrev Number: 3986 C:\DJGPP-2.04\BIN/objdump.exe: Warning: DIE at offset b3 refers to abbreviation number 3986 which does not exist Contents of the .debug_abbrev section: [snip, truncated by me] Offset: 0x6e0a Length: 78 DWARF Version: 2 Prologue Length: 58 Minimum Instruction Length: 1 Initial value of 'is_stmt': 1 Line Base: -5 Line Range: 14 Opcode Base: 13 [snip, truncated by me] C:\DJGPP-2.04\BIN/objdump.exe: Warning: Unable to load/parse the .debug_info section, so cannot interpret the .debug_loc section. C:\DJGPP-2.04\BIN/objdump.exe: Warning: Unable to load/parse the .debug_info section, so cannot interpret the .debug_ranges section. Contents of the .debug_macro section: [snip, truncated by me] ----------------------- end of objdump output ------------------------------- Please note that I have intentionally truncated a lot of the output produced by objdump. But I think that everyone can see that the debug info stored in the file has been corrupted. An inspection of the repository of binutils, specially a comparision between the binutil-2_25-branch/master and the binutil-2_24-branch reveals that the function _bfd_coff_generic_relocate_section in bfd/cofflink.c has been modified by the following patch (55bfc9ac025c1c9cd1ad5422829b3dc70f357a79): Autor: Nick Clifton 2014-03-26 17:16:20 Eintragender: Nick Clifton 2014-03-26 17:16:20 Eltern: 318d3177f7d67dac94baa07aab04192fc7bcba49 (Remove VAR_DOMAIN/STRUCT_DOMAIN ambiguity from ada-tasks.c.) Kind: b3fe4307a625457c6953fce27bbbfc4c90e38e9d (Add support for %hi8, %hi16 and %lo16 being used when relocation are necessary.) Zweig: binutils-2_25-branch, master, remotes/origin/binutils-2_25-branch and many more (44) Folgt auf: binu_ss_19990502, readline_4_0 Vorgänger von: binutils-2_25, gdb-7.8-release, gdb-7.9.0-release, hjl/linux/release/2.24.51.0.4 This fixes a problem for 64-bit Cygwin, where building some packages can produce spurious errors about truncated relocations. The relocations are only truncated because they are being made against sections which are going to be discarded so that base address is zero instead of the expected 64-bit base value. * cofflink.c (_bfd_coff_generic_relocate_section): Skip relocations in discarded sections. @@ -3059,6 +3059,11 @@ _bfd_coff_generic_relocate_section (bfd *output_bfd, else { sec = sections[symndx]; + + /* If the output section has been discarded then ignore this reloc. */ + if (sec->output_section->vma == 0) + continue; + val = (sec->output_section->vma + sec->output_offset + sym->n_value); Because the DJGPP port is an absolute _generic_ 32-bit coff system I suspect that the patch above has probably brocken almost every coff 32-bit systems except for pe-coff may be. I have solved the issue for myself by this change: diff --git a/bfd/cofflink.c b/bfd/cofflink.c index ef9e362..162d832 100644 --- a/bfd/cofflink.c +++ b/bfd/cofflink.c @@ -2979,9 +2979,13 @@ _bfd_coff_generic_relocate_section (bfd *output_bfd, { sec = sections[symndx]; + + /* Only if not a 32-bit system. */ +#ifndef __DJGPP__ /* If the output section has been discarded then ignore this reloc. */ if (sec->output_section->vma == 0) continue; +#endif val = (sec->output_section->vma + sec->output_offset Of course this should not be fixed in this way. Unfortunately my bfd skills are to limited to disign a solution that would identify that coff version that requires the ignoring of the discarded relocations and those versions that do not. If someone creates a solution for this issue and need assitance to test it, please contact me. Regards, Juan M. Guerrero