ANNOUNCE: DJGPP port of GNU binutils 2.23.2 uploaded.

[Juan Manuel Guerrero]

This is a port of GNU binutils 2.23.2 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 both.
Please note, that due to limitations inherent to DOS and memory
resources
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 specif 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 libttool 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 port has been compiled on WinXP Pro SP3 using GCC 4.7.2 and LFN
support.
I have never tried to use the linker with any gcc version previous
than 4.7.2.
I even do not know if this would ever work.



To compile the sources you will need LFN support. I have compiled on
WinXP Prof SP3. I have not tried to compile the sources using any other
Windows version. Especially I have not tried to compile it on plain DOS.
To be able to configure and compile 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 2013-03-31):

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

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

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

GNU binutils 2.23.2 source:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu2232s.zip


The binaries have been produced a second time using the stock version of
djdev204 beta library. This package is available at ftp.delorie.com and
mirrors as (timestamp 2013-03-31):

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

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


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


Enjoy.

Guerrero, Juan Manuel <juan.g...@gmx.de>

[RayeR]

Isn't possible to use dynamic allocation instead hardcoding to 10MB or anything else?

[rug...@gmail.com]

Hi,

On Friday, April 12, 2013 4:59:08 PM UTC-5, RayeR wrote:
>
> Isn't possible to use dynamic allocation instead
> hardcoding to 10MB or anything else?

Dunno, probably the best person to ask would be CWS.

According to the DJGPP FAQ (section 15.9), this is
"due to a bug/feature of the DPMI 0.9 specification"
(or maybe certain programs' sources don't use the
"static" storage qualifier enough).

http://www.delorie.com/djgpp/v2faq/faq15_9.html

From what little I understand, other systems are more
lenient (e.g. Linux), where "ulimit" often says
"unlimited", hence egregious stack chomping often
goes unnoticed there.

[Charles Sandmann]

>> Isn't possible to use dynamic allocation instead
>> hardcoding to 10MB or anything else?
>
> Dunno, probably the best person to ask would be CWS.

The issue is memory layout. In a real OS you can have
sparse memory allocation; so the stack can grow down from
the top of the address space (like 0x7ffc000 down) while
the image and malloc() data grow up (from like 0x4000).

Since DPMI 0.9 provides only "ask for size and you get
an address" type allocation, we have to use a fixed stack
size. With a full DPMI 1.0 host (or under DJGPP 1.x)
you could have an expand down stack that would
grow and fault in new pages.

[RayeR]

Aha, so no way under DPMI 0.9 to implement classic grow-down stack? But you can allocate block of memory at specific address range (or not?) - near top of memory. Hm, you probably mean tthat this block cannot overlap heap area so there's fixed boundaries of this blocks...
I know CWSDPMI support some functionality of DPMI 1.0 but not this?

[Charles Sandmann]

>"RayeR" <gl...@centrum.cz> wrote in message
>news:12d60e38-9778-4463...@googlegroups.com...

>Aha, so no way under DPMI 0.9 to implement classic grow-down stack?

Not and have it expand and have SS=DS=CS. If SS can be independent we could
move it and rebase it, but that breaks the
flat 32-bit model.

>But you can allocate block of memory at specific address range (or not?) -
>near top of memory.

No, you cannot specify an address in DPMI 0.9 (except when mapping a
hardware device). You request a block of a specific size and DPMI 0.9
returns it (wherever it wants, not necessarily anyplace near where your
current blocks are).

>I know CWSDPMI support some functionality of DPMI 1.0 but not this?

The issue is that by 1998, about 99% of DJGPP users were using some other
DPMI provider (mostly in Win95 or Win98), so coding to an enhanced standard
unsupported by MS was futile.

[RayeR]

OK, understand.
But even if we don't have ability of grow down stac it could be possible to allocate dynamic-sized block at startup. Eg. to set min and max limits where the current value could vary according to amount of available RAM. So e.g. under plain DOS where all belongs to us we could allocate, say, 10MB of 256MB, 20MB of 512MB... 40MB of 2GB for stack or so. Could be better that one fixed value for wide range HW from 386 with 4MB up to icore with 4GB... :)

[Charles Sandmann]

>"RayeR" <gl...@centrum.cz> wrote in message

>news:79342766-b269-46cb...@googlegroups.com...

This could be done (say use a % of the memory) - which will also have its
flaws. Most of my applications have well
defined stack usage and use malloc() for storage - so you would take away
available memory from those apps. So we
would need a new convention (to be able to set absolute size or relative
size). Then you have issues basing this
on physical or real memory (many DPMI providers lie about this). The source
is out there, so someone just needs
to be motivated enough to do it.