Mail Archives: djgpp-workers/2001/04/25/06:32:18
On Wed, 25 Apr 2001, Eli Zaretskii wrote:
> On Wed, 25 Apr 2001, Pierre Muller wrote:
[...]
> > Doesn't this need a hack to gcc to load the modifed crt0.o
> > instead of the ordinary one?
>
> You are right, crt0.o is not in the library. Which means sbrk cannot be
> easily replaced without modifying crt0.S.
[...]
> So GCC doesn't have much to do with this issue.
Insofar as you don't view the specs file as an integral part of GCC: yes.
Well, to some part, this might have been expected. Core file writing is
traditionally a task handled by the Unix kernel itself, AFAIK. For the
case of DJGPP, that means the relevant code will have it's "obvious" home
in or very close to the startup code: one of stub, crt0 or crt1,
essentially.
But the real problem is a different one, of course: sbrk() is currently
not just written in assembly, to make it hard to modify. There are two
versions of it, whose supporting code is spread over half of crt0.S (not
to mention the 16bit code fragment sbrk16.asm), and all of that in almost
undocumented assembly. It's not quite "Mel" code, but close to it :-(
For a somewhat simpler solution, it might suffice to activate the existing
but disabled provisions for an brk_sbrk_hook() function. Unfortunately,
the hook function in its current shape doesn't get informed about the
actual size of the block either (only handle and start). But in principle,
such a hook could memorize the block sizes in another array parallel to
__djgpp_memory_handle_list[].
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -