unexelf on irix (kinda digest)
First off all, my appologies - I've been a bit busy with "another"
open-source project recently, so I'd try to reply to everybody at once
now.
Jan Vroonhof writes:
:> Max Matveev <makc(a)sgi.com> writes:
:> > :> What exactly was wrong?
:> > Assumption that .bss section should be outside the PT_LOADable
:> > segment. On IRIX with version 6.2 and above, .bss (or .sbss, if it's
:> > present) is inside the 'data' segment. This would fail the test which
:> > was used to find a segment to grow and cover new heap. Instead of this
:> > assumption, I created another one - on IRIX the segment to grow should
:> > start below .bss and it's address should extent above the end of
:> > .bss. Once thise segment is identified, it's grown to accomodate the
:> > new heap and new zero-length .bss section is added at the end of
:> > data2.
:>
:> Ok thanks for writing this, it would be nice to have this comment
:> verbatim in unexelfsgi.c
Am I right to assume that Colin is doing it?
Jan Vroonhof writes:
:> Colin Rafferty <colin(a)xemacs.org> writes:
:>
:> > If I were to just submit the iris*.h and unexecsgi.c part, along with
:> > a proper changelog, would that be fine?
:>
:> No. What needs to be done
:>
:> 1. The etags stuff separated off (the patch is fine it just needs to
:> be separate).
:> 2. The patch to unexecsgi.c part needs to include a comment on how the
:> new code works (Max Matveev later send this seperately).
:> 3. The patch to the iris*.h stuff needs to be rewritten such as to
:> only do this for Irix 6.x. I have a prototype patch for that.
:> 4. Everything needs changelogs
:>
:> Basically all the stuff is there it just needs to be cleaned up (_and
:> tested_) before it gets in, so that we can later see what happened and
:> why. Otherwise the patch ping-pong just continues.
Let me know once it's ready - I'll respin it. Plus it may get in
before the next sgi freeware release (which is feb.00), so for the
change we would be almost in sync with the rest of the world.
Jan Vroonhof writes:
:> Alexandre Oliva <oliva(a)lsd.ic.unicamp.br> writes:
:>
:> > The GNU Emacs people have found out that my latest patch for
:> > unexelf.c, that enabled unexelf.c on IRIX, would break IRIX 6 builds:
:> > the dumped emacs would core dump on start-up. It was only possible to
:> > proceed the build by stripping temacs, which means it was not
:> > debuggable :-(
:>
:> Colin/Max, could check whether Alexandre's versions also fixes your problem.
No, it's not - it follows the same assumption, that .bss in not to be
loaded, which (from the CS201 point of view) puzzles me a bit: who's
creating a TLB entries for the stack data if they're not marked as
loadable? Looks like some kind of run-time linker magikc here.
Alexandre Oliva writes:
:> > Assumption that .bss section should be outside the PT_LOADable
:> > segment. On IRIX with version 6.2 and above, .bss (or .sbss, if it's
:> > present) is inside the 'data' segment. This would fail the test which
:> > was used to find a segment to grow and cover new heap.
:>
:> Would unexelf.c + the latest patch I've submitted fail here? It had
:> worked for me, but I could only test it with gcc 2.95.2.
Yes, it would. Or, if the stars are in the good position, it would
just success by the skin of the teeth (my very first attempt on
unexelf.c was exactly that - uncomment few debugging messages and
bingo, it works, but only on one machine).
:> If this assumption turns out to be true on any other ELF system, it
:> might be worth porting your work to unexelf.c in general.
I've checked on both IRIX 6.X and Linux 2.X and it looks like the
assumption that start of .bss is at the very least should be inside
the LOADable segment is correct. In the worst (best) possible case
.bss starts right at the end of w/r segment in the ELF file.
Jan Vroonhof writes:
:> Jan "I-am-dreaming-of-a-p-dumper" Vroonhof
^^^^^^^^^^^^^^^^^^^^^^^^^^^
I'd second that any day!
Olivier Galibert writes:
:> On Mon, Dec 06, 1999 at 09:04:15AM -0200, Alexandre Oliva wrote:
:> > I have found out the `.got' section didn't need special handling on
:> > IRIX either, at least when the compiler was gcc. If this is confirmed
:> > with other compilers too, the special handling might also be removed
:> > from unexelfsgi.c, or we might remain with unexelf.c, even on IRIX6.
:>
:> Beware of sgi's compiler. Really.
SGI compiler is ok, SGI's rld is a bit more involved, thou, especially
if rqs or cord were around. So, to be on the safe side, I'd say - keep
the stuff as it is, don't move it. After all, we don't need nothing in
the sections which are not in .bss or .sbss, so just leave them as
they are.
:> A test to do is to compile an xemacs on 6.2 and run it on 6.5.
I'm writing that using such a beast. Moreover, we (sgi freeware
people) are trying to build stuff in such a way, that it would run on
any irix starting from 6.2 upward. It works. Most of the time...
max