* Re: current bk goes BUG on ia64 when dumping core
2003-10-05 7:24 current bk goes BUG on ia64 when dumping core Andrew Morton
@ 2003-10-05 7:38 ` Andrew Morton
2003-10-06 6:41 ` Roland McGrath
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Andrew Morton @ 2003-10-05 7:38 UTC (permalink / raw)
To: linux-ia64
Andrew Morton <akpm@osdl.org> wrote:
>
> kernel BUG at fs/binfmt_elf.c:1366!
This is inside the ELF_CORE_WRITE_EXTRA_PHDRS macro btw.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: current bk goes BUG on ia64 when dumping core
2003-10-05 7:24 current bk goes BUG on ia64 when dumping core Andrew Morton
2003-10-05 7:38 ` Andrew Morton
@ 2003-10-06 6:41 ` Roland McGrath
2003-10-06 12:34 ` Andrew Morton
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Roland McGrath @ 2003-10-06 6:41 UTC (permalink / raw)
To: linux-ia64
> When running the latest LTP code, it dies in the new coredump code.
This is what I predicted when I sent the second ia64 version of the patch.
Please refer to that message for complete testing instructions to verify
the core format is correct (assuming it doesn't crash any more with the new
patch). I've made another cosmetic change to avoid using "vsyscall" in
variable names, and here is that version of the patch relative to the
current 2.6 tree.
Thanks,
Roland
Index: linux-2.5/include/asm-ia64/elf.h
=================================RCS file: /home/cvs/linux-2.5/include/asm-ia64/elf.h,v
retrieving revision 1.11
diff -u -b -p -r1.11 elf.h
--- linux-2.5/include/asm-ia64/elf.h 3 Oct 2003 22:45:47 -0000 1.11
+++ linux-2.5/include/asm-ia64/elf.h 6 Oct 2003 04:53:23 -0000
@@ -218,20 +218,23 @@ do { \
#define ELF_CORE_EXTRA_PHDRS (GATE_EHDR->e_phnum)
#define ELF_CORE_WRITE_EXTRA_PHDRS \
do { \
- const struct elf_phdr *const vsyscall_phdrs = \
+ const struct elf_phdr *const gate_phdrs = \
(const struct elf_phdr *) (GATE_ADDR + GATE_EHDR->e_phoff); \
int i; \
- Elf32_Off ofs = 0; \
+ Elf64_Off ofs = 0; \
for (i = 0; i < GATE_EHDR->e_phnum; ++i) { \
- struct elf_phdr phdr = vsyscall_phdrs[i]; \
+ struct elf_phdr phdr = gate_phdrs[i]; \
if (phdr.p_type = PT_LOAD) { \
- BUG_ON(ofs != 0); \
- ofs = phdr.p_offset = offset; \
phdr.p_memsz = PAGE_ALIGN(phdr.p_memsz); \
phdr.p_filesz = phdr.p_memsz; \
+ if (ofs = 0) { \
+ ofs = phdr.p_offset = offset; \
offset += phdr.p_filesz; \
} \
else \
+ phdr.p_offset = ofs; \
+ } \
+ else \
phdr.p_offset += ofs; \
phdr.p_paddr = 0; /* match other core phdrs */ \
DUMP_WRITE(&phdr, sizeof(phdr)); \
@@ -239,13 +242,15 @@ do { \
} while (0)
#define ELF_CORE_WRITE_EXTRA_DATA \
do { \
- const struct elf_phdr *const vsyscall_phdrs = \
+ const struct elf_phdr *const gate_phdrs = \
(const struct elf_phdr *) (GATE_ADDR + GATE_EHDR->e_phoff); \
int i; \
for (i = 0; i < GATE_EHDR->e_phnum; ++i) { \
- if (vsyscall_phdrs[i].p_type = PT_LOAD) \
- DUMP_WRITE((void *) vsyscall_phdrs[i].p_vaddr, \
- PAGE_ALIGN(vsyscall_phdrs[i].p_memsz)); \
+ if (gate_phdrs[i].p_type = PT_LOAD) { \
+ DUMP_WRITE((void *) gate_phdrs[i].p_vaddr, \
+ PAGE_ALIGN(gate_phdrs[i].p_memsz)); \
+ break; \
+ } \
} \
} while (0)
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: current bk goes BUG on ia64 when dumping core
2003-10-05 7:24 current bk goes BUG on ia64 when dumping core Andrew Morton
2003-10-05 7:38 ` Andrew Morton
2003-10-06 6:41 ` Roland McGrath
@ 2003-10-06 12:34 ` Andrew Morton
2003-10-07 5:06 ` current bk goes BUG on ia64 when dumping core; FIXED, PATCH Peter Chubb
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Andrew Morton @ 2003-10-06 12:34 UTC (permalink / raw)
To: linux-ia64
Roland McGrath <roland@redhat.com> wrote:
>
> > When running the latest LTP code, it dies in the new coredump code.
>
> This is what I predicted when I sent the second ia64 version of the patch.
> Please refer to that message for complete testing instructions to verify
> the core format is correct (assuming it doesn't crash any more with the new
> patch). I've made another cosmetic change to avoid using "vsyscall" in
> variable names, and here is that version of the patch relative to the
> current 2.6 tree.
OK, thanks.
Now, Linus is trying to get a good 2.6.0-test7 out the door early this week
and it's not helpful that ia64 goes BUG every time it wants to dump core!
I am in Tokyo and am not able to test your patch. Could someone please
apply Roland's patch to current -bk, then run Linux Test Project (it BUGged
in two seconds for me) and then send the patch to Linus fairly promptly?
Thanks.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: current bk goes BUG on ia64 when dumping core; FIXED, PATCH
2003-10-05 7:24 current bk goes BUG on ia64 when dumping core Andrew Morton
` (2 preceding siblings ...)
2003-10-06 12:34 ` Andrew Morton
@ 2003-10-07 5:06 ` Peter Chubb
2003-10-07 5:19 ` Roland McGrath
2003-10-07 8:17 ` Peter Chubb
5 siblings, 0 replies; 7+ messages in thread
From: Peter Chubb @ 2003-10-07 5:06 UTC (permalink / raw)
To: linux-ia64
>>>>> "Andrew" = Andrew Morton <akpm@osdl.org> writes:
Andrew> Roland McGrath <roland@redhat.com> wrote:
>> > When running the latest LTP code, it dies in the new coredump
>> code.
>>
>> This is what I predicted when I sent the second ia64 version of the
>> patch. Please refer to that message for complete testing
>> instructions to verify the core format is correct (assuming it
>> doesn't crash any more with the new patch). I've made another
>> cosmetic change to avoid using "vsyscall" in variable names, and
>> here is that version of the patch relative to the current 2.6 tree.
The new version doesn't BUG. I couldn't find the message you were
referring to, Roland ... However, gdb understands the core dump; and
objdump shows a .auxv section that looks the right size etc.
Andrew> I am in Tokyo and am not able to test your patch. Could
Andrew> someone please apply Roland's patch to current -bk, then run
Andrew> Linux Test Project (it BUGged in two seconds for me) and then
Andrew> send the patch to Linus fairly promptly?
And the patch, repeated from Roland McGrath's message.
Index: linux-2.5/include/asm-ia64/elf.h
=================================RCS file: /home/cvs/linux-2.5/include/asm-ia64/elf.h,v
retrieving revision 1.11
diff -u -b -p -r1.11 elf.h
--- linux-2.5/include/asm-ia64/elf.h 3 Oct 2003 22:45:47 -0000 1.11
+++ linux-2.5/include/asm-ia64/elf.h 6 Oct 2003 04:53:23 -0000
@@ -218,20 +218,23 @@ do { \
#define ELF_CORE_EXTRA_PHDRS (GATE_EHDR->e_phnum)
#define ELF_CORE_WRITE_EXTRA_PHDRS \
do { \
- const struct elf_phdr *const vsyscall_phdrs = \
+ const struct elf_phdr *const gate_phdrs = \
(const struct elf_phdr *) (GATE_ADDR + GATE_EHDR->e_phoff); \
int i; \
- Elf32_Off ofs = 0; \
+ Elf64_Off ofs = 0; \
for (i = 0; i < GATE_EHDR->e_phnum; ++i) { \
- struct elf_phdr phdr = vsyscall_phdrs[i]; \
+ struct elf_phdr phdr = gate_phdrs[i]; \
if (phdr.p_type = PT_LOAD) { \
- BUG_ON(ofs != 0); \
- ofs = phdr.p_offset = offset; \
phdr.p_memsz = PAGE_ALIGN(phdr.p_memsz); \
phdr.p_filesz = phdr.p_memsz; \
+ if (ofs = 0) { \
+ ofs = phdr.p_offset = offset; \
offset += phdr.p_filesz; \
} \
else \
+ phdr.p_offset = ofs; \
+ } \
+ else \
phdr.p_offset += ofs; \
phdr.p_paddr = 0; /* match other core phdrs */ \
DUMP_WRITE(&phdr, sizeof(phdr)); \
@@ -239,13 +242,15 @@ do { \
} while (0)
#define ELF_CORE_WRITE_EXTRA_DATA \
do { \
- const struct elf_phdr *const vsyscall_phdrs = \
+ const struct elf_phdr *const gate_phdrs = \
(const struct elf_phdr *) (GATE_ADDR + GATE_EHDR->e_phoff); \
int i; \
for (i = 0; i < GATE_EHDR->e_phnum; ++i) { \
- if (vsyscall_phdrs[i].p_type = PT_LOAD) \
- DUMP_WRITE((void *) vsyscall_phdrs[i].p_vaddr, \
- PAGE_ALIGN(vsyscall_phdrs[i].p_memsz)); \
+ if (gate_phdrs[i].p_type = PT_LOAD) { \
+ DUMP_WRITE((void *) gate_phdrs[i].p_vaddr, \
+ PAGE_ALIGN(gate_phdrs[i].p_memsz)); \
+ break; \
+ } \
} \
} while (0)
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: current bk goes BUG on ia64 when dumping core; FIXED, PATCH
2003-10-05 7:24 current bk goes BUG on ia64 when dumping core Andrew Morton
` (3 preceding siblings ...)
2003-10-07 5:06 ` current bk goes BUG on ia64 when dumping core; FIXED, PATCH Peter Chubb
@ 2003-10-07 5:19 ` Roland McGrath
2003-10-07 8:17 ` Peter Chubb
5 siblings, 0 replies; 7+ messages in thread
From: Roland McGrath @ 2003-10-07 5:19 UTC (permalink / raw)
To: linux-ia64
> The new version doesn't BUG. I couldn't find the message you were
> referring to, Roland ... However, gdb understands the core dump; and
> objdump shows a .auxv section that looks the right size etc.
Thanks for testing this! This change is not related to the NT_AUXV note in
fact (both just happened the same week). What you should be looking for is
the readelf -l (objdump -p) output from the core file, for the segment with
vaddr 0xa000000000010000 (GATE_ADDR). Check that its size is PAGE_SIZE.
You can also verify it in gdb while looking at the core file by checking
that e.g. "p (char *) 0xa000000000010000" shows "ELF\177" and that
"x/w 0xa000000000010000+PAGE_SIZE-8" (substituting the right PAGE_SIZE value)
works (and shows you zeros).
Thanks,
Roland
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: current bk goes BUG on ia64 when dumping core; FIXED, PATCH
2003-10-05 7:24 current bk goes BUG on ia64 when dumping core Andrew Morton
` (4 preceding siblings ...)
2003-10-07 5:19 ` Roland McGrath
@ 2003-10-07 8:17 ` Peter Chubb
5 siblings, 0 replies; 7+ messages in thread
From: Peter Chubb @ 2003-10-07 8:17 UTC (permalink / raw)
To: linux-ia64
>>>>> "Roland" = Roland McGrath <roland@redhat.com> writes:
>> The new version doesn't BUG. I couldn't find the message you were
>> referring to, Roland ... However, gdb understands the core dump;
>> and objdump shows a .auxv section that looks the right size etc.
Roland> Thanks for testing this! This change is not related to the
Roland> NT_AUXV note in fact (both just happened the same week). What
Roland> you should be looking for is the readelf -l (objdump -p)
Roland> output from the core file, for the segment with vaddr
Roland> 0xa000000000010000 (GATE_ADDR). Check that its size is
Roland> PAGE_SIZE. You can also verify it in gdb while looking at the
Roland> core file by checking that e.g. "p (char *)
Roland> 0xa000000000010000" shows "ELF\177" and that "x/w
Roland> 0xa000000000010000+PAGE_SIZE-8" (substituting the right
Roland> PAGE_SIZE value) works (and shows you zeros).
All those tests pass.
--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories, all slightly different.
^ permalink raw reply [flat|nested] 7+ messages in thread