[patch] Fix Darwin breakage

[patch] Fix Darwin breakage

[Paul Pluzhnikov]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

Greetings,

This patch:
  http://sourceware.org/ml/gdb-patches/2009-07/msg00417.html
caused Darwin/MacOSX to stop working with assertion:
  objfiles.c:793: internal-error: qsort_cmp: Assertion
`obj_section_endaddr (sect1) <= sect2_addr' failed.

Turns out this worked only "by accident" before.

Here is a proposed fix. Tested by running "./gdb ./gdb", setting
breakpoints, etc.
(I don't have dejagnu setup on MacOS yet).

Thanks,
-- 
Paul Pluzhnikov

2009-08-14  Paul Pluzhnikov  <ppluzhnikov@google.com>

        * objfiles.h (OBJF_NOT_MAPPED): New macro.
        * objfiles.c (update_section_map): Ignore unmapped objfiles.
        * machoread.c (macho_oso_symfile): Set OBJF_NOT_MAPPED for oso files.

[-- Attachment #2: gdb-macho-20090814.txt --]
[-- Type: text/plain, Size: 2834 bytes --]

Index: machoread.c
===================================================================
RCS file: /cvs/src/src/gdb/machoread.c,v
retrieving revision 1.5
diff -p -u -r1.5 machoread.c
--- machoread.c	19 Jun 2009 14:30:30 -0000	1.5
+++ machoread.c	14 Aug 2009 16:08:50 -0000
@@ -406,7 +406,7 @@ macho_oso_symfile (struct objfile *main_
 	      bfd_close (member_bfd);
 	    }
 	    else
-	      symbol_file_add_from_bfd (member_bfd, 0, addrs, 0);
+	      symbol_file_add_from_bfd (member_bfd, 0, addrs, OBJF_NOT_MAPPED);
 	}
       else
 	{
@@ -429,7 +429,7 @@ macho_oso_symfile (struct objfile *main_
 	      continue;
 	    }
   
-	  symbol_file_add_from_bfd (abfd, 0, addrs, 0);
+	  symbol_file_add_from_bfd (abfd, 0, addrs, OBJF_NOT_MAPPED);
 	}
       xfree (oso->symbols);
       xfree (oso->offsets);
@@ -592,7 +592,7 @@ macho_symfile_read (struct objfile *objf
 	  oso_vector = NULL;
 
 	  /* Now recurse: read dwarf from dsym.  */
-	  symbol_file_add_from_bfd (dsym_bfd, 0, NULL, 0);
+	  symbol_file_add_from_bfd (dsym_bfd, 0, NULL, OBJF_NOT_MAPPED);
       
 	  /* Don't try to read dwarf2 from main file or shared libraries.  */
 	  return;
Index: objfiles.c
===================================================================
RCS file: /cvs/src/src/gdb/objfiles.c,v
retrieving revision 1.91
diff -p -u -r1.91 objfiles.c
--- objfiles.c	10 Aug 2009 22:09:22 -0000	1.91
+++ objfiles.c	14 Aug 2009 16:08:50 -0000
@@ -840,16 +840,20 @@ update_section_map (struct obj_section *
     & SEC_THREAD_LOCAL) == 0)
 
   map_size = 0;
-  ALL_OBJSECTIONS (objfile, s)
-    if (insert_p (objfile, s))
-      map_size += 1;
+  ALL_OBJFILES (objfile)	
+    if ((objfile->flags & OBJF_NOT_MAPPED) == 0)
+      ALL_OBJFILE_OSECTIONS (objfile, s)
+	if (insert_p (objfile, s))
+	  map_size += 1;
 
   map = xmalloc (map_size * sizeof (*map));
 
   i = 0;
-  ALL_OBJSECTIONS (objfile, s)
-    if (insert_p (objfile, s))
-      map[i++] = s;
+  ALL_OBJFILES (objfile)	
+    if ((objfile->flags & OBJF_NOT_MAPPED) == 0)
+      ALL_OBJFILE_OSECTIONS (objfile, s)
+	if (insert_p (objfile, s))
+	  map[i++] = s;
 
 #undef insert_p
 
Index: objfiles.h
===================================================================
RCS file: /cvs/src/src/gdb/objfiles.h,v
retrieving revision 1.61
diff -p -u -r1.61 objfiles.h
--- objfiles.h	4 Aug 2009 18:46:05 -0000	1.61
+++ objfiles.h	14 Aug 2009 16:08:50 -0000
@@ -414,6 +414,12 @@ struct objfile
 
 #define OBJF_USERLOADED	(1 << 3)	/* User loaded */
 
+/* This objfile is not mapped into the process address space. We only have it
+   for its debug bits.  One example is MACH-O ("other source") object
+   files.  */
+
+#define OBJF_NOT_MAPPED (1 << 4)        /* Not mapped */
+
 /* The object file that the main symbol table was loaded from (e.g. the
    argument to the "symbol-file" or "file" command).  */
 

Re: [patch] Fix Darwin breakage

[Paul Pluzhnikov]

On Fri, Aug 14, 2009 at 9:22 AM, Paul Pluzhnikov<ppluzhnikov@google.com> wrote:

> Here is a proposed fix.

I just realized that I should probably also turn OBJF_NOT_MAPPED
for separate debuginfo files like this:

Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.241
diff -u -p -u -r1.241 symfile.c
--- symfile.c   10 Aug 2009 22:09:22 -0000      1.241
+++ symfile.c   14 Aug 2009 17:32:33 -0000
@@ -2534,8 +2534,9 @@ reread_separate_symbols (struct objfile
             info_verbose ? SYMFILE_VERBOSE : 0,
             0, /* No addr table.  */
             objfile->section_offsets, objfile->num_sections,
-            objfile->flags & (OBJF_REORDERED | OBJF_SHARED | OBJF_READNOW
-                              | OBJF_USERLOADED)));
+            (objfile->flags & (OBJF_REORDERED | OBJF_SHARED | OBJF_READNOW
+                              | OBJF_USERLOADED)
+            | OBJF_NOT_MAPPED));
       objfile->separate_debug_objfile->separate_debug_objfile_backlink
         = objfile;
     }

so I don't have to sort/eliminate duplicates later in objfiles.c
update_section_map, and audit other places (if any) where
symbol_file_add* routines are called as well.

I'll do that, if the initial patch is deemed roughly correct.

Thanks,
-- 
Paul Pluzhnikov

Re: [patch] Fix Darwin breakage

[Tom Tromey]

>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:

Paul> 2009-08-14  Paul Pluzhnikov  <ppluzhnikov@google.com>
Paul>         * objfiles.h (OBJF_NOT_MAPPED): New macro.
Paul>         * objfiles.c (update_section_map): Ignore unmapped objfiles.
Paul>         * machoread.c (macho_oso_symfile): Set OBJF_NOT_MAPPED for oso files.

The idea seems reasonable enough to me, but I don't really understand
all the implications of it.  If we need special treatment here, why not
in all the other places that use ALL_OBJSECTIONS and the like?

Tom

Re: [patch] Fix Darwin breakage

[Tom Tromey]

>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:

Paul> I just realized that I should probably also turn OBJF_NOT_MAPPED
Paul> for separate debuginfo files like this:

This also seems reasonable in the abstract.
I think you probably would also need to do this in
symbol_file_add_with_addrs_or_offsets.

Tom

Re: [patch] Fix Darwin breakage

[Paul Pluzhnikov]

On Fri, Aug 14, 2009 at 11:30 AM, Tom Tromey<tromey@redhat.com> wrote:

> The idea seems reasonable enough to me, but I don't really understand
> all the implications of it.  If we need special treatment here, why not
> in all the other places that use ALL_OBJSECTIONS and the like?

Good question.

I looked in gcore.c, and it looks like it should similarly skip
OBJF_NOT_MAPPED objfiles.

In main.c, I am not sure, but possibly.

In printcmd.c, it's already skipping some (but not all!):

  ALL_OBJSECTIONS (objfile, osect)
  {
    /* Only process each object file once, even if there's a separate
       debug file.  */
    if (objfile->separate_debug_objfile_backlink)
      continue;

In spu-tdep.c and symfile.c all uses have to do with overlays,
and I *think* they should similarly skip.

On Fri, Aug 14, 2009 at 11:32 AM, Tom Tromey<tromey@redhat.com> wrote:

> I think you probably would also need to do this in
> symbol_file_add_with_addrs_or_offsets.

Right, that's what '*' in 'symbol_file_add*' was supposed to convey.
Perhaps I should have used regexp instead of shell glob :-)

Thanks,
-- 
Paul Pluzhnikov

Re: [patch] Fix Darwin breakage

[Christian Thalinger]

Paul Pluzhnikov wrote:
> Greetings,
> 
> This patch:
>   http://sourceware.org/ml/gdb-patches/2009-07/msg00417.html
> caused Darwin/MacOSX to stop working with assertion:
>   objfiles.c:793: internal-error: qsort_cmp: Assertion
> `obj_section_endaddr (sect1) <= sect2_addr' failed.
> 
> Turns out this worked only "by accident" before.
> 
> Here is a proposed fix. Tested by running "./gdb ./gdb", setting
> breakpoints, etc.
> (I don't have dejagnu setup on MacOS yet).

I tried that patch and it kind of works.  But running a program takes
ages (about 5-10 minutes), with GDB using 100% CPU time.

A backtrace looks like this:

(gdb) thr 6
[Switching to thread 6 (Thread 0x2703 of process 55928)]#0  0x94e9c136
in __semwait_signal_nocancel () from /usr/lib/libSystem.B.dylib
(gdb) bt
#0  0x94e9c136 in __semwait_signal_nocancel () from
/usr/lib/libSystem.B.dylib
#1  0x94e9bd1b in nanosleep$NOCANCEL$UNIX2003 () from
/usr/lib/libSystem.B.dylib
#2  0x94e95013 in usleep$NOCANCEL$UNIX2003 () from
/usr/lib/libSystem.B.dylib
#3  0x94eac62e in __abort () from /usr/lib/libSystem.B.dylib
#4  0x94eac68a in abort () from /usr/lib/libSystem.B.dylib
#5  0x01ebdcaa in os::abort(bool) () from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#6  0x0206cf4e in VMError::report_and_die() () from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#7  0x01b03c4a in report_assertion_failure(char const*, int, char
const*) () from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#8  0x01ed2cf9 in Compile::Fill_buffer() () from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#9  0x01ed4d53 in Compile::Output() () from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#10 0x01a93198 in Compile::Code_Gen() () from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#11 0x01a93795 in Compile::Compile(ciEnv*, TypeFunc const* (*)(),
unsigned char*, char const*, int, bool, bool, bool) () from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#12 0x01f68030 in OptoRuntime::generate_stub(ciEnv*, TypeFunc const*
(*)(), unsigned char*, char const*, int, bool, bool, bool) () from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#13 0x01f680ba in OptoRuntime::generate(ciEnv*) () from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#14 0x019cfeac in C2Compiler::initialize_runtime() () from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#15 0x01771c9e in AbstractCompiler::initialize_runtimes (this=0x11e148,
f=0x19cfd6a <C2Compiler::initialize_runtime()>, state=0x21c955c) at
/Users/twisti/bsd-port/hotspot/src/share/vm/compiler/abstractCompiler.cpp:50
#16 0x019cff11 in C2Compiler::initialize() () from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#17 0x019cff88 in C2Compiler::compile_method(ciEnv*, ciMethod*, int) ()
from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#18 0x01a9e00c in CompileBroker::invoke_compiler_on_method(CompileTask*)
() from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#19 0x01a9e744 in CompileBroker::compiler_thread_loop() () from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#20 0x020103c8 in compiler_thread_entry(JavaThread*, Thread*) () from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#21 0x02011eac in JavaThread::thread_main_inner() () from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#22 0x02012031 in JavaThread::run() () from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#23 0x01ebdeb6 in java_start(Thread*) () from
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
#24 0x94df1155 in _pthread_start () from /usr/lib/libSystem.B.dylib
#25 0x94df1012 in thread_start () from /usr/lib/libSystem.B.dylib
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

#26 0x00000000 in ?? ()

The backtrace looks fine, but arguments and local variables are not
visible.  Loaded shared libraries look OK:

(gdb) info sharedlibrary
From        To          Syms Read   Shared Object Library
0x01771b90  0x026a7c27  Yes
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/libjvm.dylib
0x94dc00c0  0x94f67fbf  Yes         /usr/lib/libSystem.B.dylib
0x96160780  0x9616904b  Yes         /usr/lib/libgcc_s.1.dylib
0x910d3fb4  0x9113f6f2  Yes         /usr/lib/libstdc++.6.dylib
0x975e12b0  0x975e500c  Yes         /usr/lib/system/libmathCommon.A.dylib
0x0000d850  0x00018130  Yes
/Users/twisti/bsd-port/hotspot/build/bsd/jdk-bsd-i586/debug/jre/lib/i386/libverify.dylib
0x000267e0  0x00041379  Yes
/Users/twisti/bsd-port/hotspot/build/bsd/jdk-bsd-i586/debug/jre/lib/i386/libjava.dylib
0x0004e390  0x00053248  Yes
/Users/twisti/bsd-port/hotspot/build/bsd/jdk-bsd-i586/debug/jre/lib/i386/native_threads/libhpi.dylib
0x000720f0  0x0008210d  Yes
/Users/twisti/bsd-port/hotspot/build/bsd/jdk-bsd-i586/debug/jre/lib/i386/libzip.dylib

-- Christian

Re: [patch] Fix Darwin breakage

[Paul Pluzhnikov]

On Tue, Aug 18, 2009 at 4:52 AM, Christian
Thalinger<Christian.Thalinger@sun.com> wrote:

> I tried that patch and it kind of works.  But running a program takes
> ages (about 5-10 minutes), with GDB using 100% CPU time.

Could you attach another instance of GDB to the one that consumes 100%
CPU and see where the CPU-bound GDB is? (Or use dtrace to get ustack
histogram :-)

> The backtrace looks fine, but arguments and local variables are not
> visible.  Loaded shared libraries look OK:

Steps to reproduce?
Could you make a tar of /Users/twisti/bsd-port/hotspot/build/ available?

Thanks,
-- 
Paul Pluzhnikov

Re: [patch] Fix Darwin breakage

[Christian Thalinger]

Paul Pluzhnikov wrote:
> On Tue, Aug 18, 2009 at 4:52 AM, Christian
> Thalinger<Christian.Thalinger@sun.com> wrote:
> 
>> I tried that patch and it kind of works.  But running a program takes
>> ages (about 5-10 minutes), with GDB using 100% CPU time.
> 
> Could you attach another instance of GDB to the one that consumes 100%
> CPU and see where the CPU-bound GDB is? (Or use dtrace to get ustack
> histogram :-)

Yeah, I should do that.

> 
>> The backtrace looks fine, but arguments and local variables are not
>> visible.  Loaded shared libraries look OK:
> 
> Steps to reproduce?
> Could you make a tar of /Users/twisti/bsd-port/hotspot/build/ available?

The problem is the size of the stuff you need:

$ du -sc build/bsd/bsd_i486_compiler2/ build/bsd/jdk-bsd-i586/
562996	build/bsd/bsd_i486_compiler2/
745016	build/bsd/jdk-bsd-i586/
1308012	total

I should try something smaller...

-- Christian

Re: [patch] Fix Darwin breakage

[Paul Pluzhnikov]

On Thu, Aug 20, 2009 at 9:42 AM, Christian
Thalinger<Christian.Thalinger@sun.com> wrote:

> The problem is the size of the stuff you need:
>
> $ du -sc build/bsd/bsd_i486_compiler2/ build/bsd/jdk-bsd-i586/
> 1308012 total

Is that in blocks of 512B, or blocks of 1KB?

I think we can arrange to transfer a 1GB file (it will likely compress
reasonably well), though it may be easiest for me to just drive to Santa
Clara and pick up a CD or DVD (if you are in fact in the bay area).

> I should try something smaller...

Or I could try building jdk locally (are there many dependencies?)

Thanks,
-- 
Paul Pluzhnikov

Re: [patch] Fix Darwin breakage

[Christian Thalinger]

Paul Pluzhnikov wrote:
> On Thu, Aug 20, 2009 at 9:42 AM, Christian
> Thalinger<Christian.Thalinger@sun.com> wrote:
> 
>> The problem is the size of the stuff you need:
>>
>> $ du -sc build/bsd/bsd_i486_compiler2/ build/bsd/jdk-bsd-i586/
>> 1308012 total
> 
> Is that in blocks of 512B, or blocks of 1KB?

It's 512B blocks:

$ du -sch build/bsd/bsd_i486_compiler2/ build/bsd/jdk-bsd-i586/
275M	build/bsd/bsd_i486_compiler2/
364M	build/bsd/jdk-bsd-i586/
639M	total

> 
> I think we can arrange to transfer a 1GB file (it will likely compress
> reasonably well), though it may be easiest for me to just drive to Santa
> Clara and pick up a CD or DVD (if you are in fact in the bay area).

The drive would be long... I'm in Vienna, Austria :-)

> 
>> I should try something smaller...
> 
> Or I could try building jdk locally (are there many dependencies?)

It's not that complicated.  I try a fresh build and if it's fairly easy,
I send you the instructions.

-- Christian

Re: [patch] Fix Darwin breakage

[Christian Thalinger]

Paul Pluzhnikov wrote:
> On Thu, Aug 20, 2009 at 9:42 AM, Christian
> Thalinger<Christian.Thalinger@sun.com> wrote:
> 
>> The problem is the size of the stuff you need:
>>
>> $ du -sc build/bsd/bsd_i486_compiler2/ build/bsd/jdk-bsd-i586/
>> 1308012 total
> 
> Is that in blocks of 512B, or blocks of 1KB?
> 
> I think we can arrange to transfer a 1GB file (it will likely compress
> reasonably well), though it may be easiest for me to just drive to Santa
> Clara and pick up a CD or DVD (if you are in fact in the bay area).
> 
>> I should try something smaller...
> 
> Or I could try building jdk locally (are there many dependencies?)

Just for the record, I sent Paul build instructions in private.

-- Christian