From: Ali Bahrami <ali_gnu@emvision.com>
To: Dan Nicolaescu <dann@ics.uci.edu>
Cc: emacs-devel@gnu.org
Subject: Re: Question about dumping emacs under Solaris
Date: Fri, 04 Jul 2008 12:34:55 -0600 [thread overview]
Message-ID: <486E6D4F.5060807@emvision.com> (raw)
In-Reply-To: <200807040739.m647daXU022629@sallyv1.ics.uci.edu>
Dan Nicolaescu wrote:
> Ali Bahrami <ali_gnu@emvision.com> writes:
>
> > Hello,
> >
> > I have a question about how emacs is dumped under
> > Solaris. In the file emacs/src/s/sol-2-6.h:
> >
> > /* Handle Solaris 2.6. */
> >
> > #include "sol2-5.h"
> >
> > #if 0 /* dldump does not handle all the extensions used by GNU ld. */
> > #undef UNEXEC
> > #define UNEXEC unexsol.o
> > #endif
> >
> > This ifdef prevents the unexsol.c code, containing a call
> > to dldump(), from being used. Instead, the generic ELF unexec
> > code is used. Looking at the RCS revisions, I see that dldump()
> > was disabled in revision 1.3 of the file, dating from
> > September 13, 2002.
> >
> > Can anyone shed any light on what GNU ld extensions are not
> > properly handled by the Solaris dldump()? I know that 2002
> > was a while ago, and possibly no one remembers, but it
> > would be helpful to know what went wrong.
> >
> > I work at Sun, on the linker. We've discussed this, and are at
> > a loss as to what the problem might be. dldump() is pretty
> > generic, and nothing leaps out as being unable to support GNU
> > ld objects. There are some differences between the ELF objects
> > produced by the Solaris and GNU, but they tend to be pretty
> > compatible for the most part.
>
> Regardless if anyone remembers why those changes were made, positive
> proof that the code works is the best option.
>
> Given what you said above, you are probably able to experiment with
> building with various versions of both Sun and GNU tools, on various
> Solaris versions and check if emacs works correctly.
>
> If things work OK, then there's no reason not to enable the code in
> question immediately.
In the absence of any other information, that's probably
the best we can do. I can do the obvious tests (build it,
show it runs, use it for awhile). That's not what I'd call
positive proof, but it may be our only path forward.
I should probably provide more details on why I'm asking about
this. I built an emacs recently on solaris, and then ran
elfdump on it:
% elfdump emacs 2>&1
When you run elfdump this way (throwing away stdout), what's
left are the errors --- things elfdump is suspicious about
in the object. Ideally, there's no output. In the case of
emacs, it generates a large number of errors regarding overlap
of the symbol table and the data sections. This happens because
the bss section in the original temacs gets turned into actual
data in the object, which ends up being written where the symbol
table was. The resulting object runs fine, but has a corrupt
symbol table, which might be an issue for debuggers and
other observability tools. dldump() rewrites the output object
in a way that shifts the non-allocable stuff (including the symbol
table) down and preserves them.
That's the main advantage of dldump() --- it's not like the generic
ELF code isn't working adequately. For that reason, I'm not
particularly concerned about older Solaris versions. They can keep
dumping emacs in the old way. My interest is solely for the current
head of the Solaris tree, which we call Nevada internally, and
which is visible via OpenSolaris.
So my test matrix is really pretty small. Solaris and GNU
ld, on sparc and intel. I've already built the Solaris ld versions
with dldump(), and have been using it as my daily editor for
most of last week without issue. I'll keep poking at it, and
if things seem solid, perhaps I'll submit the change.
Thanks for your help.
- Ali
next prev parent reply other threads:[~2008-07-04 18:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-04 4:06 Question about dumping emacs under Solaris Ali Bahrami
2008-07-04 7:39 ` Dan Nicolaescu
2008-07-04 18:34 ` Ali Bahrami [this message]
2008-07-04 19:51 ` Stefan Monnier
2008-07-04 11:46 ` Eli Zaretskii
2008-07-04 20:52 ` Ali Bahrami
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=486E6D4F.5060807@emvision.com \
--to=ali_gnu@emvision.com \
--cc=dann@ics.uci.edu \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.