Re: Dumper produces unuseable dumps (fix).
On May 26 23:42, Pedro Alves wrote: > Corinna Vinschen wrote: > > > >Ping! The papers have found their way to our office and are already > >signed. > > > > Great! That's a relief. > > >You said you have an updated patch? > > Yep. Here it is. > > human-made-inter-diff: > - set lma == 0 > - fixed buglet in the windows->elf protection mappings. Thanks, applied. I simplified the ChangeLog entry slightly. The revision number is controlled by CVS anyway, so I don't think it makes sense to mention it in the ChangeLog. Thanks again, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Dumper produces unuseable dumps (fix).
Corinna Vinschen wrote:
Ping! The papers have found their way to our office and are already
signed.
Great! That's a relief.
You said you have an updated patch?
Yep. Here it is.
human-made-inter-diff:
- set lma == 0
- fixed buglet in the windows->elf protection mappings.
Cheers,
Pedro Alves
2007-05-26 Pedro Alves <[EMAIL PROTECTED]>
* dumper.cc (version): Bump to 1.15.
(dumper::prepare_core_dump): Record a phdr for
each section.
---
dumper.cc | 63 ++
1 file changed, 59 insertions(+), 4 deletions(-)
Index: utils/dumper.cc
===
--- utils.orig/dumper.cc 2007-05-26 23:21:12.0 +0100
+++ utils/dumper.cc 2007-05-26 23:40:34.0 +0100
@@ -1,6 +1,6 @@
/* dumper.cc
- Copyright 1999, 2001, 2002, 2004, 2006 Red Hat Inc.
+ Copyright 1999, 2001, 2002, 2004, 2006, 2007 Red Hat Inc.
Written by Egor Duda <[EMAIL PROTECTED]>
@@ -37,7 +37,7 @@ __attribute__ ((packed))
#endif
note_header;
-static const char version[] = "$Revision: 1.14 $";
+static const char version[] = "$Revision: 1.15 $";
BOOL verbose = FALSE;
@@ -657,6 +657,8 @@ dumper::prepare_core_dump ()
{
sect_no++;
+ unsigned long phdr_type = PT_LOAD;
+
switch (p->type)
{
case pr_ent_memory:
@@ -664,7 +666,7 @@ dumper::prepare_core_dump ()
sect_flags = SEC_HAS_CONTENTS | SEC_ALLOC | SEC_LOAD;
sect_size = p->u.memory.size;
sect_vma = (bfd_vma) (p->u.memory.base);
-
+ phdr_type = PT_LOAD;
break;
case pr_ent_thread:
@@ -672,6 +674,7 @@ dumper::prepare_core_dump ()
sect_flags = SEC_HAS_CONTENTS | SEC_LOAD;
sect_size = sizeof (note_header) + sizeof (struct win32_pstatus);
sect_vma = 0;
+ phdr_type = PT_NOTE;
break;
case pr_ent_module:
@@ -680,6 +683,7 @@ dumper::prepare_core_dump ()
sect_size = sizeof (note_header) + sizeof (struct win32_pstatus) +
(bfd_size_type) (strlen (p->u.module.name));
sect_vma = 0;
+ phdr_type = PT_NOTE;
break;
default:
@@ -722,11 +726,62 @@ dumper::prepare_core_dump ()
};
new_section->vma = sect_vma;
+ new_section->lma = 0;
new_section->output_section = new_section;
new_section->output_offset = 0;
p->section = new_section;
-}
+ int section_count = 1;
+
+ bfd_boolean filehdr = 0;
+ bfd_boolean phdrs = 0;
+
+ bfd_vma at = 0;
+ bfd_boolean valid_at = 0;
+
+ flagword flags = 0;
+ bfd_boolean valid_flags = 1;
+
+ if (p->type == pr_ent_memory)
+ {
+ MEMORY_BASIC_INFORMATION mbi;
+ if (!VirtualQueryEx (hProcess, (LPVOID)sect_vma, &mbi, sizeof (mbi)))
+ {
+ bfd_perror ("getting mem region flags");
+ goto failed;
+ }
+
+ static const struct
+ {
+ DWORD protect;
+ flagword flags;
+ } mappings[] =
+ {
+ { PAGE_READONLY, PF_R },
+ { PAGE_READWRITE, PF_R | PF_W },
+ { PAGE_WRITECOPY, PF_W },
+ { PAGE_EXECUTE, PF_X },
+ { PAGE_EXECUTE_READ, PF_X | PF_R },
+ { PAGE_EXECUTE_READWRITE, PF_X | PF_R | PF_W },
+ { PAGE_EXECUTE_WRITECOPY, PF_X | PF_W }
+ };
+
+ for (size_t i = 0;
+ i < sizeof (mappings) / sizeof (mappings[0]);
+ i++)
+ if ((mbi.Protect & mappings[i].protect) != 0)
+ flags |= mappings[i].flags;
+ }
+ if (!bfd_record_phdr (core_bfd, phdr_type,
+ valid_flags, flags,
+ valid_at, at,
+ filehdr, phdrs,
+ section_count, &new_section))
+ {
+ bfd_perror ("recording program headers");
+ goto failed;
+ }
+}
return 1;
failed:
Re: Dumper produces unuseable dumps (fix).
Hi Pedro, On May 22 09:16, Corinna Vinschen wrote: > On May 21 22:33, Pedro Alves wrote: > > Please ping me when the papers are in; I may have an > > updated patch by then. > > Sure. Thanks for following through. Ping! The papers have found their way to our office and are already signed. You said you have an updated patch? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Dumper produces unuseable dumps (fix).
On May 21 22:33, Pedro Alves wrote: > Please ping me when the papers are in; I may have an > updated patch by then. Sure. Thanks for following through. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Dumper produces unuseable dumps (fix).
Pedro Alves wrote: I'll have new papers from my employer in a few days, and I'll resubmit them. Just to let you know: Papers signed and sent. Let's hope this time the plain doesn't go any near the Bermuda Triangle. Please ping me when the papers are in; I may have an updated patch by then. Cheers, Pedro Alves
Re: Dumper produces unuseable dumps (fix).
On May 17 13:29, Pedro Alves wrote: > To be sure, the snail address at: > > http://cygwin.com/assign.txt > > ... is still the correct one, right? Yep. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Dumper produces unuseable dumps (fix).
On 5/15/07, Corinna Vinschen <[EMAIL PROTECTED]> wrote: I just asked at our office and I got told that your copyright assignment didn't arrive yet. Can you check what happened? Have no idea... Should have been there by now. Bummer. I'll have new papers from my employer in a few days, and I'll resubmit them. To be sure, the snail address at: http://cygwin.com/assign.txt ... is still the correct one, right? Cheers, Pedro Alves
Re: Dumper produces unuseable dumps (fix).
Hi Pedro, On Apr 27 16:01, Pedro Alves wrote: > On 4/27/07, Corinna Vinschen wrote: > > >Unfortunately, the patch is too big to fall under the trivial patch > >rule, so Red Hat needs a signed copyright assignment from you. > >Please have a look on http://cygwin.com/contrib.html, especially the > >"Before you get started" section, which has a link to the assignment > >form. As soon as we got the signed form from you, the patch can go > >in. > > > > Ok, form signed and sent. I just asked at our office and I got told that your copyright assignment didn't arrive yet. Can you check what happened? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Dumper produces unuseable dumps (fix).
On Fri, Apr 27, 2007 at 04:01:29PM +0100, Pedro Alves wrote: >On 4/27/07, Corinna Vinschen wrote: > >>Unfortunately, the patch is too big to fall under the trivial patch >>rule, so Red Hat needs a signed copyright assignment from you. >>Please have a look on http://cygwin.com/contrib.html, especially the >>"Before you get started" section, which has a link to the assignment >>form. As soon as we got the signed form from you, the patch can go >>in. >> > >Ok, form signed and sent. Hopefully you + your employer... cgf
Re: Dumper produces unuseable dumps (fix).
On 4/27/07, Corinna Vinschen wrote: Unfortunately, the patch is too big to fall under the trivial patch rule, so Red Hat needs a signed copyright assignment from you. Please have a look on http://cygwin.com/contrib.html, especially the "Before you get started" section, which has a link to the assignment form. As soon as we got the signed form from you, the patch can go in. Ok, form signed and sent. Thanks. Cheers, Pedro Alves
Re: Dumper produces unuseable dumps (fix).
Hi Pedro, On Apr 26 21:37, Pedro Alves wrote: > Hi guys, > > I noticed that dumper isn't working for me, silently exiting > without producing a dump, so I tried building it from source. > The problem was that the bfd_set_arch_mach (core_bfd, bfd_arch_i386, 0) > call was failing. I couldn't debug it, since it was linked > into the system /usr/lib/libbfd.a, which doesn't come with > debug info. I then tried to link with with a cvs bfd, and that > problem goes away. > > But, I then found out that gdb wasn't reading the dumps. After > some investigation, I found that the core file is built with > section headers, and no program headers. Since it is > bfd_make_section_from_phdr that makes the magic sections that > gdb reads from, the current dumper makes useless core dumps. > [...] > The attached patch fixes it by programatically making a > phdr for each section. I now get readable dumps. > [...] > Could this fix be considered for inclusion, please? Thanks for this patch. Unfortunately, the patch is too big to fall under the trivial patch rule, so Red Hat needs a signed copyright assignment from you. Please have a look on http://cygwin.com/contrib.html, especially the "Before you get started" section, which has a link to the assignment form. As soon as we got the signed form from you, the patch can go in. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Dumper produces unuseable dumps (fix).
Hi guys,
I noticed that dumper isn't working for me, silently exiting
without producing a dump, so I tried building it from source.
The problem was that the bfd_set_arch_mach (core_bfd, bfd_arch_i386, 0)
call was failing. I couldn't debug it, since it was linked
into the system /usr/lib/libbfd.a, which doesn't come with
debug info. I then tried to link with with a cvs bfd, and that
problem goes away.
But, I then found out that gdb wasn't reading the dumps. After
some investigation, I found that the core file is built with
section headers, and no program headers. Since it is
bfd_make_section_from_phdr that makes the magic sections that
gdb reads from, the current dumper makes useless core dumps.
eg:
>cat main.c
int asdf = 1;
int main ()
{
asdf = 30;
abort ();
}
./main.exe
dumper.exe pops up a console with a bunch of warnings like:
>./dumper.exe main.exe 5700
BFD: main.exe.core: warning: allocated section `.mem/10' not in segment
BFD: main.exe.core: warning: allocated section `.mem/11' not in segment
(...)
and gdb complains like so:
>/usr/local/bin/gdb --core=main.exe.core
GNU gdb 6.6.50.20070416-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
warning: Couldn't find general-purpose registers in core file.
warning: Couldn't find general-purpose registers in core file.
#0 0x in ?? ()
(gdb) symbol-file main.exe
Reading symbols from
/cygdrive/d/cygwin-src/build/i686-pc-cygwin/winsup/utils/main.exe...done.
(gdb) p asdf
Cannot access memory at address 0x402000
(gdb)
, and, readelf shows that:
>readelf -l main.exe.core
There are no program headers in this file.
At least linux and solaris generate dumps with
program headers, and no section headers. In gdb/bfd I
could only find support for reading the magic core
sections from phdrs, so I guess that at some point bfd
automatically generated these phdrs, but nowadays it
doesn't.
The attached patch fixes it by programatically making a
phdr for each section. I now get readable dumps.
readelf -l main.exe.core
Elf file type is CORE (Core file)
Entry point 0x0
There are 50 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000674 0x 0x 0x0032c 0x0 0x1
NOTE 0x0009a0 0x 0x 0x002f4 0x0 0x1
NOTE 0x000c94 0x 0x 0x002f4 0x0 0x1
NOTE 0x000f88 0x 0x 0x00311 0x0 0x1
NOTE 0x001299 0x 0x 0x00314 0x0 0x1
NOTE 0x0015ad 0x 0x 0x0030d 0x0 0x1
NOTE 0x0018ba 0x 0x 0x00314 0x0 0x1
NOTE 0x001bce 0x 0x 0x00312 0x0 0x1
NOTE 0x001ee0 0x 0x 0x00313 0x0 0x1
NOTE 0x0021f3 0x 0x 0x002f4 0x0 0x1
LOAD 0x0024e7 0x0001 0x0001 0x01000 0x01000 RW 0x1
LOAD 0x0034e7 0x0002 0x0002 0x01000 0x01000 RW 0x1
LOAD 0x0044e7 0x0022c000 0x0022c000 0x07000 0x07000 RW 0x1
LOAD 0x00b4e7 0x0024 0x0024 0x08000 0x08000 RW 0x1
LOAD 0x0134e7 0x0034 0x0034 0x06000 0x06000 RW 0x1
LOAD 0x0194e7 0x0035 0x0035 0x03000 0x03000 RW 0x1
(...)
GNU gdb 6.6.50.20070416-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
#0 0x7c91eb94 in ?? ()
(gdb) symbol-file main.exe
Reading symbols from
/cygdrive/d/cygwin-src/build/i686-pc-cygwin/winsup/utils/main.exe...done.
(gdb) p asdf
$1 = 30
Not forcing a higher alignment of the sections doesn't seem to have
any bad effect, so I left it out.
I see a probably unrelated problem. When using error_start to
start dumper.exe, it seems that the stack trace always starts
in a frameless dll function. I know that the dump is ok, since
I tested it by manually dumping a program stopped in a 'while (1);'
loop, and that gives an ok trace. I also confirmed that I could
print local and global variables, and that they came
up with the expected values.
Could this fix be considered for inclusion, please?
Cheers,
Pedro Alves
2007-04-26 Pedro Alves <[EMAIL PROTECTED]>
* dumper.cc (version): Bump to 1.15.
(dumper::pr
