* Dump failure on Solaris 8
@ 2009-05-05 4:13 YAMAMOTO Mitsuharu
2009-05-05 10:47 ` Andreas Schwab
0 siblings, 1 reply; 3+ messages in thread
From: YAMAMOTO Mitsuharu @ 2009-05-05 4:13 UTC (permalink / raw)
To: emacs-devel
I experienced a failure in dumping on Solaris 8 with gcc 3.4.2. The
dumped .data section was overwritten by the succeeding .symtab
section. This is due to a part of this change:
2009-02-02 Andreas Schwab <schwab@suse.de>
* unexelf.c (unexec): Handle unaligned bss offset.
*** unexelf.c 2009/01/08 03:16:02 1.69
--- unexelf.c 2009/02/02 16:07:00 1.70
***************
*** 970,985 ****
else
{
/* Any section that was originally placed after the .bss
! section should now be off by NEW_DATA2_SIZE. If a
section overlaps the .bss section, consider it to be
placed after the .bss section. Overlap can occur if the
section just before .bss has less-strict alignment; this
was observed between .symtab and .bss on Solaris 2.5.1
(sparc) with GCC snapshot 960602. */
! if (NEW_SECTION_H (nn).sh_offset + NEW_SECTION_H (nn).sh_size
! > new_data2_offset)
! NEW_SECTION_H (nn).sh_offset += new_data2_size;
/* Any section that was originally placed after the section
header table should now be off by the size of one section
--- 980,994 ----
else
{
/* Any section that was originally placed after the .bss
! section should now be off by NEW_DATA2_INCR. If a
section overlaps the .bss section, consider it to be
placed after the .bss section. Overlap can occur if the
section just before .bss has less-strict alignment; this
was observed between .symtab and .bss on Solaris 2.5.1
(sparc) with GCC snapshot 960602. */
! if (NEW_SECTION_H (nn).sh_offset >= old_bss_offset)
! NEW_SECTION_H (nn).sh_offset += new_data2_incr;
/* Any section that was originally placed after the section
header table should now be off by the size of one section
If I restore the if-condition (not including the then-clause) in the
hunk above, the dumping process works again. Actually, the comment
above the if-condition seems to tell about this case. The output of
"dump -h temacs" becomes as follows and the offset of the .bss section
(0x315158) is greater than that of the succeeding .symtab section
(0x315154).
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
src/temacs:
**** SECTION HEADER TABLE ****
[No] Type Flags Addr Offset Size Name
Link Info Adralgn Entsize
[1] 1 2 0x100d4 0xd4 0x11 .interp
0 0 0x1 0
[2] 5 2 0x100e8 0xe8 0xafa8 .hash
3 0 0x4 0x4
[3] 11 2 0x1b090 0xb090 0x15f10 .dynsym
4 1 0x4 0x10
[4] 3 34 0x30fa0 0x20fa0 0x167bf .dynstr
0 0 0x1 0
[5] 1879048190 2 0x47760 0x37760 0x1a0 .SUNW_version
4 12 0x4 0
[6] 4 66 0x47900 0x37900 0x30 .rela.got
3 14 0x4 0xc
[7] 4 66 0x47930 0x37930 0xc .rela.data
3 17 0x4 0xc
[8] 4 66 0x4793c 0x3793c 0x12c .rela.bss
3 23 0x4 0xc
[9] 4 66 0x47a68 0x37a68 0x17f4 .rela.plt
3 15 0x4 0xc
[10] 1 6 0x4925c 0x3925c 0x1815f0 .text
0 0 0x4 0
[11] 1 6 0x1ca84c 0x1ba84c 0x1c .init
0 0 0x4 0
[12] 1 6 0x1ca868 0x1ba868 0x14 .fini
0 0 0x4 0
[13] 1 2 0x1ca880 0x1ba880 0x1aa78 .rodata
0 0 0x8 0
[14] 1 3 0x1f52f8 0x1d52f8 0x34 .got
0 0 0x4 0x4
[15] 1 7 0x1f532c 0x1d532c 0x1828 .plt
0 0 0x4 0xc
[16] 6 3 0x1f6b54 0x1d6b54 0x170 .dynamic
4 0 0x4 0x8
[17] 1 3 0x1f6cc8 0x1d6cc8 0x13e470 .data
0 0 0x8 0
[18] 1 3 0x335138 0x315138 0x8 .ctors
0 0 0x4 0
[19] 1 3 0x335140 0x315140 0x8 .dtors
0 0 0x4 0
[20] 1 3 0x335148 0x315148 0x4 .eh_frame
0 0 0x4 0
[21] 1 3 0x33514c 0x31514c 0x4 .jcr
0 0 0x4 0
[22] 1 3 0x335150 0x315150 0x4 .data.rel.local
0 0 0x4 0
[23] 8 3 0x335158 0x315158 0x42720 .bss
0 0 0x8 0
[24] 2 0 0 0x315154 0x1c9d0 .symtab
25 1709 0x4 0x10
[25] 3 32 0 0x331b24 0x1d406 .strtab
0 0 0x1 0
[26] 1 0 0 0x34ef2a 0x1c0f .comment
0 0 0x1 0
[27] 1 0 0 0x350b3c 0x24 .stab.index
37 0 0x4 0xc
[28] 1 0 0 0x350b60 0x11359 .debug_abbrev
0 0 0x1 0
[29] 1 0 0 0x361eb9 0x1f35a7 .debug_info
0 0 0x1 0
[30] 1 0 0 0x555460 0x12c356 .debug_line
0 0 0x1 0
[31] 1 0 0 0x6817b8 0x15d50 .debug_frame
0 0 0x4 0
[32] 1 0 0 0x697508 0x1aa7c .debug_pubnames
0 0 0x1 0
[33] 1 0 0 0x6b1f84 0xa00 .debug_aranges
0 0 0x1 0
[34] 1 0 0 0x6b2984 0x14478 .debug_ranges
0 0 0x1 0
[35] 1 0 0 0x6c6dfc 0xd033 .debug_str
0 0 0x1 0
[36] 3 32 0 0x6d3e2f 0x14f .shstrtab
0 0 0x1 0
[37] 3 0 0 0x6d3f7e 0x176 .stab.indexstr
0 0 0x1 0
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Dump failure on Solaris 8
2009-05-05 4:13 Dump failure on Solaris 8 YAMAMOTO Mitsuharu
@ 2009-05-05 10:47 ` Andreas Schwab
2009-05-06 2:30 ` YAMAMOTO Mitsuharu
0 siblings, 1 reply; 3+ messages in thread
From: Andreas Schwab @ 2009-05-05 10:47 UTC (permalink / raw)
To: YAMAMOTO Mitsuharu; +Cc: emacs-devel
YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> If I restore the if-condition (not including the then-clause) in the
> hunk above, the dumping process works again. Actually, the comment
> above the if-condition seems to tell about this case. The output of
> "dump -h temacs" becomes as follows and the offset of the .bss section
> (0x315158) is greater than that of the succeeding .symtab section
> (0x315154).
IIRC I've changed the condition because of a problem encountered on
x86_64-linux. Unfortunately I cannot test that any more. The problem
is that the file contents of the first unallocated section may be
completely contained in the padding after the last allocated non-bss
section. Perhaps we have to check both conditions here.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Dump failure on Solaris 8
2009-05-05 10:47 ` Andreas Schwab
@ 2009-05-06 2:30 ` YAMAMOTO Mitsuharu
0 siblings, 0 replies; 3+ messages in thread
From: YAMAMOTO Mitsuharu @ 2009-05-06 2:30 UTC (permalink / raw)
To: Andreas Schwab; +Cc: emacs-devel
>>>>> On Tue, 05 May 2009 12:47:34 +0200, Andreas Schwab <schwab@linux-m68k.org> said:
>> If I restore the if-condition (not including the then-clause) in
>> the hunk above, the dumping process works again. Actually, the
>> comment above the if-condition seems to tell about this case. The
>> output of "dump -h temacs" becomes as follows and the offset of the
>> .bss section (0x315158) is greater than that of the succeeding
>> .symtab section (0x315154).
> IIRC I've changed the condition because of a problem encountered on
> x86_64-linux. Unfortunately I cannot test that any more. The
> problem is that the file contents of the first unallocated section
> may be completely contained in the padding after the last allocated
> non-bss section. Perhaps we have to check both conditions here.
That seems to be a good way at this timing. I added the old condition
instead of replacing with it.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-05-06 2:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-05 4:13 Dump failure on Solaris 8 YAMAMOTO Mitsuharu
2009-05-05 10:47 ` Andreas Schwab
2009-05-06 2:30 ` YAMAMOTO Mitsuharu
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).