bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

DJGPP port of binutils broken due to 64 bit cygwin fix.


From: Juan Manuel Guerrero
Subject: DJGPP port of binutils broken due to 64 bit cygwin fix.
Date: Thu, 04 Jun 2015 13:56:34 +0200
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

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 <http://gnu.org/licenses/gpl.html>
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:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
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><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   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
    <a1>   DW_AT_comp_dir    : a.c
    <a6>   DW_AT_producer    : c:/tmp/5
    <af>   DW_AT_language    : 7984       (Unknown: 1f30)
 <0><b1>: 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><b2>: Abbrev Number: 0
 <-2><b3>: 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 <address@hidden>  2014-03-26 17:16:20
Eintragender: Nick Clifton <address@hidden>  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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]