From: Alan Modra <amodra@gmail.com>
To: Old K <oldk1331@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Your patch on src/unexelf.c causes Emacs can't dump twice
Date: Tue, 17 Nov 2015 07:34:22 +1030 [thread overview]
Message-ID: <20151116210422.GB8120@bubble.grove.modra.org> (raw)
In-Reply-To: <CAGBJN90Q61HDtx=9eTBfgorC9qgR16kNYh9kWJiRQ2AcQKds9Q@mail.gmail.com>
On Wed, Nov 11, 2015 at 02:54:07PM +0800, Old K wrote:
> I don't know why developers decide Emacs can not call
> '(dump-emacs "newname" "path/to/emacs")' anymore, but if you apply the
> following patch, you can dump emacs again, which is a useful feature
> for me:
>
> --- a/src/emacs.c
> +++ b/src/emacs.c
> @@ -2045,9 +2045,6 @@ You must run Emacs in batch mode in order to dump
> it. */)
> if (! noninteractive)
> error ("Dumping Emacs works only in batch mode");
>
> - if (!might_dump)
> - error ("Emacs can be dumped only once");
> -
> #ifdef GNU_LINUX
>
> /* Warn if the gap between BSS end and heap start is larger than this.
> */
>
>
> You can get more information about 'dump-emacs' at
> http://www.emacswiki.org/emacs/DumpingEmacs
> (And you may have to run Emacs under GDB to dump it again.)
>
> After applying your patch set, this no longer works. Namely the last
> two patch may not proper handle .bss properly when emacs dump again.
I think that disabling the might_dump test in emacs.c is dangerous and
you will find that dumping emacs more than once is unreliable. See
https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01698.html
However, the following might work for you. Please report back to the
list whether it does. I haven't tested this patch beyond checking
that it doesn't break the first emacs dump.
diff --git a/src/unexelf.c b/src/unexelf.c
index c10c7f2..d2aca0c 100644
--- a/src/unexelf.c
+++ b/src/unexelf.c
@@ -310,24 +310,39 @@ unexec (const char *new_name, const char *old_name)
/* Note that old_bss_addr may be lower than the first bss section
address, since the section may need aligning. */
old_bss_addr = old_bss_seg->p_vaddr + old_bss_seg->p_filesz;
- old_bss_offset = old_bss_seg->p_offset + old_bss_seg->p_filesz;
old_bss_size = old_bss_seg->p_memsz - old_bss_seg->p_filesz;
- /* Find the last bss style section in the bss segment range. */
+ /* Find the last section in old_bss_seg. */
old_bss_index = -1;
for (n = old_file_h->e_shnum; --n > 0; )
{
ElfW (Shdr) *shdr = &OLD_SECTION_H (n);
- if (shdr->sh_type == SHT_NOBITS
- && shdr->sh_addr >= old_bss_addr
- && shdr->sh_addr + shdr->sh_size <= old_bss_addr + old_bss_size
- && (old_bss_index == -1
- || OLD_SECTION_H (old_bss_index).sh_addr < shdr->sh_addr))
- old_bss_index = n;
+ if (shdr->sh_addr >= old_bss_seg->p_vaddr
+ && (shdr->sh_addr + shdr->sh_size
+ <= old_bss_seg->p_vaddr + old_bss_seg->p_memsz))
+ {
+ if (old_bss_index == -1
+ || OLD_SECTION_H (old_bss_index).sh_addr < shdr->sh_addr)
+ old_bss_index = n;
+
+ if (old_bss_size == 0)
+ {
+ /* If we are dumping emacs a second time then the bss
+ region has been converted to have file backing. */
+ if (old_section_names[shdr->sh_name] == ','
+ && old_bss_addr > shdr->sh_addr)
+ old_bss_addr = shdr->sh_addr;
+ }
+ }
}
if (old_bss_index == -1)
- fatal ("no bss section found");
+ fatal ("no section in last segment");
+
+ old_bss_offset = (old_bss_seg->p_offset
+ + (old_bss_addr - old_bss_seg->p_vaddr));
+ old_bss_size = (old_bss_seg->p_memsz
+ - (old_bss_addr - old_bss_seg->p_vaddr));
new_break = sbrk (0);
new_bss_addr = (ElfW (Addr)) new_break;
@@ -408,8 +423,7 @@ unexec (const char *new_name, const char *old_name)
ElfW (Shdr) *old_shdr = &OLD_SECTION_H (n);
ElfW (Shdr) *new_shdr = &NEW_SECTION_H (n);
- if (new_shdr->sh_type == SHT_NOBITS
- && new_shdr->sh_addr >= old_bss_addr
+ if (new_shdr->sh_addr >= old_bss_addr
&& (new_shdr->sh_addr + new_shdr->sh_size
<= old_bss_addr + old_bss_size))
{
--
Alan Modra
Australia Development Lab, IBM
parent reply other threads:[~2015-11-16 21:04 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <CAGBJN90Q61HDtx=9eTBfgorC9qgR16kNYh9kWJiRQ2AcQKds9Q@mail.gmail.com>]
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151116210422.GB8120@bubble.grove.modra.org \
--to=amodra@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=oldk1331@gmail.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).