delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2014/12/27/22:55:30

X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Message-Id: <201412280354.sBS3sqPX023484@delorie.com>
Date: Sat, 27 Dec 2014 23:24:16 +0100
From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
To: djgpp-announce AT delorie DOT com
Subject: ANNOUNCE: DJGPP port of GNU binutils 2.25 uploaded.
Reply-To: djgpp AT delorie DOT com

This is a port of GNU binutils 2.25 to MSDOS/DJGPP.

   The GNU binutils are utilities of use when dealing with binary files, either
   object files or executables.  These tools consist of the linker (ld), the
   assembler (gas), and the profiler (gprof).  There is also a collection of
   other binary tools, including the disassembler (objdump).  These tools make
   use of a pair of libraries (bfd and opcodes) and a common set of header files.



   DJGPP specific changes.
   =======================
   - This port allows a maximal number of 4294967296 relocations per object file
     and a maximal number of 4294967296 of lines per executable file.
     The previous limits were the classical COFF limitations of 65536 for boths.
     Please note, that due to limitations inherent to DOS and memory ressources
     not every file can be compiled.  E.g.: to be able to compile a single file
     containing up to 3 * 65536 relocations I had to increment stack space of
     cc1.exe from 2MB to 10MB.  If the file contains 4 * 65536 relocations then
     cc1.exe aborts because memory has become exhausted.  Neither as.exe nor
     ld.exe have shown memory issues.  Both have the standard stack space of
     512KB.  In other words, even if 32 bit values for relocation and line
     counters are now supported by DJGPP port of as.exe and ld.exe it does not
     imply that large files can be successfully compiled and linked. There are
     memory limitations that may not be solvable.
     OFYI how the DJGPP specifc support for number of relocations greater than
     64K works:
      - If the number of relocations of an object file exceeds 65534 then
        s_nreloc in the section header is set to 65535 to signal the overflow
        and the real number of relocations is stored in an extra COFF relocation
        directive.  This is always the first relocation directive in the sequence
        of relocation directives of this object file.  The 32 bit field r_vaddr
        is used to store the real number of relocations.  This extra relocation
        directive is later removed.  To signal this overflow also the
        STYP_NRELOC_OVFL bit (0x01000000) is set in the s_flags field of the
        section header.
      - If the number of lines of an object file exceeds 65535 then the assembler
        will abort with an error message.  This can only happen if COFF debug info
        is used.  There is no work around for this issue.
      - When the linker creates an executable file from the objects files and
        the total number of lines exceeds 65535 the lower 16 bit of that value
        will be stored in the s_nlnno field and the higher 16 bit in the s_nreloc
        field of the section header of the executable file.  This can only happen
        if COFF debug info is used.

   - The linker script changes, are based on the diff files taken from Andris
     Pavenis' bnu219s2.zip and djcross-binutils-2.19.1-10ap.src.rpm. Both are
     available at ftp.delorie.com and mirrors.
     I have only made those adjustments necessaries to get those patches fit with
     the current source files.

   - The diffs file that contains all changes I have done is stored in the /djgpp
     directory.  Also in this directory is stored the small build.sh script that
     I have used to adjust all configure and libtool scripts of the package.  The
     well known issues that must been fixed are that:
     1) the gawk test for setting the CR coding to be used does not work at all.
     2) inhibit that gawk prepends a leading slash to DOS style path names.
     3) a libtool function needs to be adjusted to get the install target
        working.
     4) the target alias is removed from the tooldir and scriptdir path to get
        the programs and linker scripts installed in the canonical places of a
        DJGPP installation.
     That script is very simple and will only work to configure and compile the
     sources in the /djgpp directory.  If you want to make changes or pass more
     or other options to configure, you will have to edit it or write your own
     script.  build.sh shall not be smart, it shall only DTRT.

   - The linker script has been adapted to discard LTO sections created by the
     compiler if the -flto flag is passed to the compiler.  This is due to LTO
     specific file names that are not 8.3 clean especially if the -save-temps
     option is used.  This may change in the future when the djgpp port of the
     compiler fully supports LTO.

   - This port provides a version of the linker that will be capable to resolve
     multiple symbol definitions conflicts when using DXE3 modules. Multiple
     symbol definition always occur when an application is linked with various
     libraries and more than one of its provides an object file defining the
     same function (symbol).  E.g.: when compiling an arbitrary GNU source
     package like grep with NLS enabled and using the DXE3 module versions of
     the iconv library and the gettext library, a definition of the locale_charset
     function (aka symbol) will appear three times.  One definition (aka
     function implementation) will be provided by the grep code itself via its
     own code (aka libgreputils.a).  The other two will be provided by the import
     libraries libiconv.a and libintl.a of both DXE3 modules used. The linker
     will note that the different libraries provide different implementations of
     the same function and will abort operation with an error message like this:

c:/djgpp-2.04/lib/libintl.a(dxe_tmp.o):dxe_tmp.c:(.text+0x7a4): multiple definition of `locale_charset'
../lib/libgreputils.a(localcharset.o):h:/g/srcs/gnu/grep-2.18/_build.204/lib/.././../lib/localcharset.c:363: first defined here
c:/djgpp-2.04/lib/libiconv.a(dxe_tmp.o):dxe_tmp.c:(.text+0x248): multiple definition of `locale_charset'
../lib/libgreputils.a(localcharset.o):h:/g/srcs/gnu/grep-2.18/_build.204/lib/.././../lib/localcharset.c:363: first defined here
collect2.exe: error: ld returned 1 exit status

     In case of multiple symbol definitions, the linker will check if one of the
     definitions comes from an import library (all import libraries contain only
     one single object file called dxe_tmp.o).  If the symbol definition is stored
     in a file called dxe_tmp.o, all other definitions will be ignored/discarded.
     This means that the symbol definition of the DXE3 module has __always__
     precedence over any other symbol definition.  This will guarantee that all
     compiled programs that use the same DXE3 module will use at runtime the
     same implementation of the required function and not a particular
     implementation provided by the sources of the program being compiled.  That
     implementation may not even have been ported to djgpp and thus will be
     useless at all.  There is no linker switch to change this behavior and to
     give any other function implementation precedence over the DXE3 implementation.
     If more than one import library provides a definition for the same symbol,
     always the first is used and all other import library definitions are ignored.
     This is not an issue because the import libraries only provide wrapper
     functions that call at runtime the real functions stored in the DXE3 modules
     and these wrapper functions look all the same.  Without this capability,
     the DXE3 modules become almost useless for NLS support, because the porter
     of every package that has NLS enabled would have to take care to remove all
     NLS specific functions from the port code that are already provided either
     by the gettext library or by the iconv library.  Please note that the linker
     cannot resolve any other multiple symbol definition conflict than the one
     described for the DXE3 modules.  Of course, if static library versions of
     those NLS libraries are used, these symbol conflicts do not arise at all
     and the linker creates an executable in the usual way.
     The linker version with this feature has been compiled using a freshly
     compiled version of libc.a from the CVS repository.  You can download
     an archive of the repository tree at:
<http://www.ludd.luth.se/~ams/djgpp/cvs/djgpp.cvs.tar.gz>
     To be able to compile the linker with this feature you must uncomment
     the line that defines the DXE3_SUPPORT_ENABLED variable in the
     /djgpp/build.sh file.

   - There are ports like the one of GNU gettext that provide libraries with
     file names that cannot be uniquely mapped to short file names without
     using numeric tails.  Usually in this case the files are renamed so they
     have a valid short file name without having to use numeric tails.  The
     consequence of this renaming is that a lot of Makefiles need to be
     adjusted in a DJGPP/DOS specific way.  To avoid this inconvenience, this
     version of the linker will provide a mapping feature between the original
     long file names and the DOS specific short file names.  This port provides
     a new file called libnames.tab located in /dev/env/DJDIR/lib. When the
     linker tries to open a library with its original name and fails, it will
     try to open /dev/env/DJDIR/lib/libnames.tab and load it content into a
     static array/table.  With the aid of this table it will try to map the
     long file name to a short file name.  If this mapping is successful it
     will try to load that file instead of the original one and if this was
     also succesfull it will continue working.  For every other library that
     cannot be loaded by its original name, the linker will search for an
     alternative name in the array/table and load that library instead.  Please
     note that you cannot specific the location of libnames.tab.  If required,
     the linker will load it from the canonical location and there will be no
     error message if libnames.tab cannot be found or loaded.  If the linker
     cannot load the library neither by its original name nor by its short
     name it will abort the operation in the usual way and issue an error
     message about file loading error printing the original file name.
     The syntax for the entries is quite simple and the scanning/reading of
     the file is not bullet-proof.  This means that syntax errors will not be
     detected and will produce nonsense file name translations that will very
     likely make abort the linker.  I do not think that this is a great
     inconvenience because most of the users should never add any entry to
     this file.  It is the job of the port of some package that must provide
     an update of libnames.tab if his port contains renamed libraries.
     Syntax of libnames.tab entries:
     1) The # character defines comment line that will be skipped.
        The comment is the complete line and NOT only the text following the
        # character!
     2) Empty lines will be skipped.
     3) A valid entry looks like:

withverylongname-1.2   wvln12

        Neither the prefix nor the suffix/extension of the library name is
        part of the table entry.  For the above example the complete file
        name of the library would be:
          libwithverylongname-1.2.a
        To get a valid entry strip the prefix "lib" and the suffix ".a" from
        the library name.  The same applies to the short file name of the
        library.  In the example above, the library has been renamed to:
          libwvln12.a
        and that is the file name of the library that the linker will use.
        The original file name is always the first name and the substitute
        file name is the second name.  Both names are separated by at least
        one space or tab character.
        Another example:  the gettext port provides a library that has been
        renamed to libgtxtsrc.a.  Its original name was libgettextsrc.a.
        The entry for this library looks like this:

gettextsrc     gtxtsrc

        As can be seen the "lib" prefix and the ".a" suffix have been stripped
        from both library names to get the table entry.  In the actual version
        of libnames.tab there are only the three entries for the three renamed
        libraries provided by the gettext port.

   - For performance reasons, BFD tries to open and cache certain amount of
     files and its contents.  How many files can be opened is determinated at
     program start using the getrlimit function.  Unfortunately this function
     seems to be a placebo function.  At least when using djdev204 on WinXP,
     this function always returns the hard coded value of 255.  This is the
     value for the number of files that can be opened (RLIMIT_NOFILE).  BFD
     takes one eight of this value but at least 10 and opens so mutch files
     as required.  If your FILES entry in config.sys is not large enough (at
     least around 35) then the program aborts.  The corresponding BFD function
     now assumes that there are at least 15 available and will use all of them
     if required.  This has the consequence that the user must set his FILES
     entry in config.sys or config.nt to 20 or 25.  The value depends on how
     much file handles the OS and the DPMI server has already consumed for its
     on needs.

   - The port has been configured and compiled on WinXP SP3.  There is no
     guarantee that this may be possible with any other DOS-like OS. Due
     to the massive use of long file names it will not be possible to configure
     and compile without LFN support.

   - The DJGPP 2.04 version of the port has been compiled using gcc492 and
     bnu224br2.  But instead of using the libc.a provided djdev204, a libc
     version compiled from the repository code has been used. The repository
     code has been patched with the memory patch as provided by Andris Pavenis
     in:
       http://ap1.pp.fi/djgpp/djdev/djgpp/20140421/use_nmalloc.diff
     The goal is to test how well the new memory system and the current libc
     code works.  The repository code can be downloaded from Martin Stromberg's
     site as:
       http://www.ludd.luth.se/~ams/djgpp/cvs/djgpp.cvs.tar.gz

   - To be able to configure and compile on WinXP using djgpp 2.03 it will be
     necessary to replace cat.exe and sort.exe with the versions compiled with
     djgpp 2.04.


   As usual, all djgpp specific files (build.sh, diffs, README files, etc.)
   are located in the /djgpp directory.  The sources have not been configured
   so you must change into the /djgpp directory and start build.sh. This will
   configure the sources and start make.

   For further information about Binutils please read the info docs and NEWS file.




   The port consists of the usual four packages that have been compiled
   using stock djdev203 and that can be downloaded from ftp.delorie.com
   and mirrors as (time stamp 2014-12-24):

     GNU binutils 2.25 binary and info format documentation:
     ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu225b.zip

     GNU binutils 2.25 bfd, liberty and opcode libraries and headers:
     ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu225a.zip

     GNU binutils 2.25 dvi, html, ps and pdf format documentation:
     ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu225d.zip

     GNU binutils 2.25 source:
     ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu225s.zip


   The binaries and library have been produced a second time using a libc.a
   version compiled from current repository code and patched with the new
   malloc code.  This package is available at ftp.delorie.com and mirrors
   as (time stamp 2014-12-24):

     GNU binutils 2.25 binary and info format documentation:
     ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/bnu225b.zip

     GNU binutils 2.25 bfd, liberty and opcode libraries and headers:
     ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/bnu225a.zip


   Send binutils specific bug reports to <bug-binutils AT gnu DOT org>.
   Send suggestions and bug reports concerning the DJGPP port to
   comp.os.msdos.djgpp or <djgpp AT delorie DOT com>.


Enjoy.

         Guerrero, Juan Manuel <juan DOT guerrero AT gmx DOT de>

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019