Emacs problem

Emacs problem

[Thomas Bogendoerfer]

I've found the cause for the emacs X11 problems. The unexec code of Emacs
doesn't handle relocations in the .rel.dyn section, because Mips seems to
be the only platform, which uses such section (sgi and sni, are using
a different implementation of unexec). This mishandling leads to an emacs
binary, which has double resolved dynamic relocations (once when dumped,
twice when executed), which leads to a seg fault. It happens only with
X11, because the relocations are only for X11 stuff.

I'll try to fix that, but it would be good to have some documentation about
the .rel.dyn section, which looks a little bit different than the i386
.rel.data section). Any pointers other than the bfd source code ?

Thomas.

-- 
See, you not only have to be a good coder to create a system like Linux,
you have to be a sneaky bastard too ;-)
                   [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>]

Re: Emacs problem

[ralf]

On Sun, Aug 23, 1998 at 10:36:47PM +0200, Thomas Bogendoerfer wrote:

> I've found the cause for the emacs X11 problems. The unexec code of Emacs
> doesn't handle relocations in the .rel.dyn section, because Mips seems to
> be the only platform, which uses such section (sgi and sni, are using
> a different implementation of unexec). This mishandling leads to an emacs
> binary, which has double resolved dynamic relocations (once when dumped,
> twice when executed), which leads to a seg fault. It happens only with
> X11, because the relocations are only for X11 stuff.
> 
> I'll try to fix that, but it would be good to have some documentation about
> the .rel.dyn section, which looks a little bit different than the i386
> .rel.data section). Any pointers other than the bfd source code ?

I think you can find the related ABI documentation on www.mipsabi.org.
What details exactly are you interested in?  I've got a printed copy at
home.

  Ralf

Re: Emacs problem

[Thomas Bogendoerfer]

On Mon, Aug 24, 1998 at 12:19:30PM +0200, ralf@uni-koblenz.de wrote:
> I think you can find the related ABI documentation on www.mipsabi.org.

ok, I've found what I was looking for.

> What details exactly are you interested in?  I've got a printed copy at
> home.

On other ELF platforms .rel section reference the section for which the
relocations are for in the sh_info section header. This field is 0 for
.rel.dyn sections. The ABI document states that the relocations for
.data and .sdata sections, so I know what I wanted to know:-)

Another questione does gcc/egcs produce .sdata, .lit4 or .li8 sections
on Linux/MIPS ?

Thomas.

-- 
See, you not only have to be a good coder to create a system like Linux,
you have to be a sneaky bastard too ;-)
                   [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>]

Re: Emacs problem

[ralf]

On Tue, Aug 25, 1998 at 10:56:03PM +0200, Thomas Bogendoerfer wrote:

> Another questione does gcc/egcs produce .sdata, .lit4 or .li8 sections
> on Linux/MIPS ?

These sections are mostly being used for code using global pointer
optimization.  .lit8 is also being used for fp code when assembling li.d
macros.

For kernel code global pointer optimization is incompatible
with our current use of $gp as the current pointer; in userland gp
optimization is incompatible with PIC code.

  Ralf

Re: Emacs problem

[Thomas Bogendoerfer]

On Fri, Aug 28, 1998 at 12:31:54PM +0200, ralf@uni-koblenz.de wrote:
> On Tue, Aug 25, 1998 at 10:56:03PM +0200, Thomas Bogendoerfer wrote:
> 
> > Another questione does gcc/egcs produce .sdata, .lit4 or .li8 sections
> > on Linux/MIPS ?
> 
> These sections are mostly being used for code using global pointer
> optimization.  .lit8 is also being used for fp code when assembling li.d
> macros.

as they don't show up in the temacs binary, I'll ignore them for unexec().

With a crude hack in unexec(), I now have a emcas binary, which will show up
an empty X window. Looking with strace and tcpdump it looks like emacs
tries to do more X work, but doesn't succeed. Stuff for the weekend ...

Thomas.

-- 
See, you not only have to be a good coder to create a system like Linux,
you have to be a sneaky bastard too ;-)
                   [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>]