status of Darwin support

status of Darwin support

[Christian Thalinger]

Hi!

I just read http://sourceware.org/ml/gdb/2008-08/msg00193.html about
Darwin support and I wanted to ask what the current status is (since
it's about 1 year ago)?

I am having some problems with the GDB shipped with Xcode and I would
like to (hopefully) get around these problems in using a different GDB
version.

Right now I can run my program in GDB but there is a problem with
debugging symbols and shared libraries.

-- Christian

Re: status of Darwin support

[Tom Tromey]

>>>>> "Twisti" == Christian Thalinger <Christian.Thalinger@Sun.COM> writes:

Hi Twisti!

Twisti> I just read http://sourceware.org/ml/gdb/2008-08/msg00193.html about
Twisti> Darwin support and I wanted to ask what the current status is (since
Twisti> it's about 1 year ago)?

Twisti> I am having some problems with the GDB shipped with Xcode and I would
Twisti> like to (hopefully) get around these problems in using a different GDB
Twisti> version.

Twisti> Right now I can run my program in GDB but there is a problem with
Twisti> debugging symbols and shared libraries.

I didn't see any answer to this.

I know that some Darwin patches have gone in since last August.
However, I don't know the current state of the port.

Could you try gdb CVS and see how it works for you?
If you run into problems, file them in bugzilla, if you would.

Tom

Re: status of Darwin support

[Thiago Jung Bauermann]

Em Terça-feira 04 Agosto 2009 13:51:58 Tom Tromey escreveu:
> >>>>> "Twisti" == Christian Thalinger <Christian.Thalinger@Sun.COM> writes:
>
> Hi Twisti!
>
> Twisti> I just read http://sourceware.org/ml/gdb/2008-08/msg00193.html
> about Twisti> Darwin support and I wanted to ask what the current status is
> (since Twisti> it's about 1 year ago)?
>
> Twisti> I am having some problems with the GDB shipped with Xcode and I
> would Twisti> like to (hopefully) get around these problems in using a
> different GDB Twisti> version.
>
> Twisti> Right now I can run my program in GDB but there is a problem with
> Twisti> debugging symbols and shared libraries.
>
> I didn't see any answer to this.
>
> I know that some Darwin patches have gone in since last August.
> However, I don't know the current state of the port.
>
> Could you try gdb CVS and see how it works for you?
> If you run into problems, file them in bugzilla, if you would.

Joel would probably know. My best guess is that even if Darwin support is much 
better now, the MI incompatibilities would mean that you wouldn't be able to 
drop FSF's GDB in place of Apple's for Xcode.
-- 
[]'s
Thiago Jung Bauermann

Re: status of Darwin support

[Joel Brobecker]

> Joel would probably know. My best guess is that even if Darwin support
> is much better now, the MI incompatibilities would mean that you
> wouldn't be able to drop FSF's GDB in place of Apple's for Xcode.

Actually, I won't know that much more. Tristan is the one who looks
after that port. As far as I know, we're using it internally, to
debug GNAT for instance, and it seems to be working well.  Thiago
is right about the bunch of local additions that Apple made to GDB,
though.

-- 
Joel

Re: status of Darwin support

[Christian Thalinger]

Thiago Jung Bauermann wrote:
> Joel would probably know. My best guess is that even if Darwin support is much 
> better now, the MI incompatibilities would mean that you wouldn't be able to 
> drop FSF's GDB in place of Apple's for Xcode.

That doesn't matter, I don't use Xcode anway.  I just need a command line
debugger.

-- Christian

Re: status of Darwin support

[Christian Thalinger]

Joel Brobecker wrote:
>> Joel would probably know. My best guess is that even if Darwin support
>> is much better now, the MI incompatibilities would mean that you
>> wouldn't be able to drop FSF's GDB in place of Apple's for Xcode.
> 
> Actually, I won't know that much more. Tristan is the one who looks
> after that port. As far as I know, we're using it internally, to
> debug GNAT for instance, and it seems to be working well.  Thiago
> is right about the bunch of local additions that Apple made to GDB,
> though.

Hmm, I have problems with shared libraries.  One thing is that the
shared library is only found when it's in the current directory,
otherwise:

(gdb) r
Starting program: /Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/gamma
dyld: Library not loaded: libjvm.dylib
  Referenced from: /Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/gamma
  Reason: image not found

Even if the path to the library is in DYLD_LIBRARY_PATH.  The other
problem is that debugging symbols for shared libraries are not loaded.
I can set a breakpoint in the main executable and debug it:

(gdb) c
Continuing.

Breakpoint 2, CreateExecutionEnvironment (_argcp=0xbffff630, _argvp=0xbffff634, jrepath=0xbffff194 "", so_jrepath=1024, jvmpath=0xbfffed94 "", so_jvmpath=1024,
    original_argv=0x1005c0) at /Users/twisti/bsd-port/hotspot/src/os/bsd/launcher/java_md.c:238
238	    char *execname = NULL;
(gdb) bt
#0  CreateExecutionEnvironment (_argcp=0xbffff630, _argvp=0xbffff634, jrepath=0xbffff194 "", so_jrepath=1024, jvmpath=0xbfffed94 "", so_jvmpath=1024, original_argv=0x1005c0)
    at /Users/twisti/bsd-port/hotspot/src/os/bsd/launcher/java_md.c:238
#1  0x00001ce6 in main (argc=2, argv=0xbffff654) at /Users/twisti/bsd-port/hotspot/src/os/bsd/launcher/java.c:250

But an assert in the shared library gives:

Current thread is 2954858496
Dumping core ...
[New Thread 0x1f03 of process 71094]
[New Thread 0x2003 of process 71094]
[New Thread 0x2103 of process 71094]
[New Thread 0x2203 of process 71094]
[New Thread 0x2303 of process 71094]
[New Thread 0x2403 of process 71094]

Program received signal SIGABRT, Aborted.
0x95bd046e in ?? ()
(gdb) info threads
  7 Thread 0x2403 of process 71094  0x95bd046e in ?? ()
  6 Thread 0x2303 of process 71094  0x95ca5136 in ?? ()
  5 Thread 0x2203 of process 71094  0x95bc92c2 in ?? ()
  4 Thread 0x2103 of process 71094  0x95bd046e in ?? ()
  3 Thread 0x2003 of process 71094  0x95bd046e in ?? ()
  2 Thread 0x1f03 of process 71094  0x95bd046e in ?? ()
* 1 Thread 0x1d03 of process 71094  0x95bd046e in ?? ()
(gdb) bt
#0  0x95bd046e in ?? ()
#1  0x95bfb3e6 in ?? ()
#2  0x00001803 in ?? ()
#3  0x00001903 in ?? ()
#4  0x00000000 in ?? ()

And yes, it has debugging symbols.  Anything I can do to change that?

-- Christian

Re: status of Darwin support

[Jonas Maebe]

On 06 Aug 2009, at 13:13, Christian Thalinger wrote:

> Hmm, I have problems with shared libraries.

It may be useful for people not on Apple's Xcode list to see what Jim  
Ingham from Apple said about that: http://lists.apple.com/archives/xcode-users/2009/Jul/msg00161.html


Jonas

Re: status of Darwin support

[Tristan Gingold]

On Aug 6, 2009, at 1:13 PM, Christian Thalinger wrote:

> Joel Brobecker wrote:
>>> Joel would probably know. My best guess is that even if Darwin  
>>> support
>>> is much better now, the MI incompatibilities would mean that you
>>> wouldn't be able to drop FSF's GDB in place of Apple's for Xcode.
>>
>> Actually, I won't know that much more. Tristan is the one who looks
>> after that port. As far as I know, we're using it internally, to
>> debug GNAT for instance, and it seems to be working well.  Thiago
>> is right about the bunch of local additions that Apple made to GDB,
>> though.
>
> Hmm, I have problems with shared libraries.  One thing is that the
> shared library is only found when it's in the current directory,
> otherwise:
>
> (gdb) r
> Starting program: /Users/twisti/bsd-port/hotspot/build/bsd/ 
> bsd_i486_compiler2/jvmg/gamma
> dyld: Library not loaded: libjvm.dylib
>  Referenced from: /Users/twisti/bsd-port/hotspot/build/bsd/ 
> bsd_i486_compiler2/jvmg/gamma
>  Reason: image not found
>
> Even if the path to the library is in DYLD_LIBRARY_PATH.

Unknown issue.  Can you try to investigate by yourself (ie, check that  
your program can see DYLD_LIBRARY_PATH and is not setuid/setgid) ?

You may also post a tiny reproducer and I will look at this when I  
have spare time.


>  The other
> problem is that debugging symbols for shared libraries are not loaded.
> I can set a breakpoint in the main executable and debug it:
>
> (gdb) c
> Continuing.
>
> Breakpoint 2, CreateExecutionEnvironment (_argcp=0xbffff630,  
> _argvp=0xbffff634, jrepath=0xbffff194 "", so_jrepath=1024,  
> jvmpath=0xbfffed94 "", so_jvmpath=1024,
>    original_argv=0x1005c0) at /Users/twisti/bsd-port/hotspot/src/os/ 
> bsd/launcher/java_md.c:238
> 238	    char *execname = NULL;
> (gdb) bt
> #0  CreateExecutionEnvironment (_argcp=0xbffff630,  
> _argvp=0xbffff634, jrepath=0xbffff194 "", so_jrepath=1024,  
> jvmpath=0xbfffed94 "", so_jvmpath=1024, original_argv=0x1005c0)
>    at /Users/twisti/bsd-port/hotspot/src/os/bsd/launcher/java_md.c:238
> #1  0x00001ce6 in main (argc=2, argv=0xbffff654) at /Users/twisti/ 
> bsd-port/hotspot/src/os/bsd/launcher/java.c:250
>
> But an assert in the shared library gives:
>
> And yes, it has debugging symbols.  Anything I can do to change that?

I have just committed a patch that may fix this issue.

Do not hesitate to report issues also gdb for Darwin is not yet  
feature full.

Tristan.

Re: status of Darwin support

[Christian Thalinger]

Tristan Gingold wrote:
>> (gdb) r
>> Starting program: /Users/twisti/bsd-port/hotspot/build/bsd/ 
>> bsd_i486_compiler2/jvmg/gamma
>> dyld: Library not loaded: libjvm.dylib
>>  Referenced from: /Users/twisti/bsd-port/hotspot/build/bsd/ 
>> bsd_i486_compiler2/jvmg/gamma
>>  Reason: image not found
>>
>> Even if the path to the library is in DYLD_LIBRARY_PATH.
> 
> Unknown issue.  Can you try to investigate by yourself (ie, check that  
> your program can see DYLD_LIBRARY_PATH and is not setuid/setgid) ?

I can say for sure it's not setuid/setgid.  I will have a look at the
other issue.

> 
> You may also post a tiny reproducer and I will look at this when I  
> have spare time.

I try to come up with one.

> I have just committed a patch that may fix this issue.

I gave it a try and I get:

(gdb) r
Starting program: /Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/gamma
objfiles.c:792: internal-error: qsort_cmp: Assertion `obj_section_endaddr (sect1) <= sect2_addr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

> 
> Do not hesitate to report issues also gdb for Darwin is not yet  
> feature full.

I will.

-- Christian

Re: status of Darwin support

[Tom Tromey]

>>>>> "Twisti" == Christian Thalinger <Christian.Thalinger@Sun.COM> writes:

Twisti> objfiles.c:792: internal-error: qsort_cmp: Assertion `obj_section_endaddr (sect1) <= sect2_addr' failed.
Twisti> A problem internal to GDB has been detected,
Twisti> further debugging may prove unreliable.

This is a recent regression.  Paul Pluzhnikov posted a patch to fix this
crash on Linux, but I don't know whether the patch will fix Darwin.
Could you give it a try?  (The patch is approved so presumably he will
be checking it in soon...)

Tom

Re: status of Darwin support

[Paul Pluzhnikov]

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

>>>>>> "Twisti" == Christian Thalinger <Christian.Thalinger@Sun.COM> writes:
>
> Twisti> objfiles.c:792: internal-error: qsort_cmp: Assertion `obj_section_endaddr (sect1) <= sect2_addr' failed.
> Twisti> A problem internal to GDB has been detected,
> Twisti> further debugging may prove unreliable.
>
> This is a recent regression.  Paul Pluzhnikov posted a patch to fix this
> crash on Linux, but I don't know whether the patch will fix Darwin.
> Could you give it a try?  (The patch is approved so presumably he will
> be checking it in soon...)

I've just committed the patch.

I will try to reproduce the Darwin failure, but I won't get to my Mac
until later tonight.

Cheers,
-- 
Paul Pluzhnikov

Re: status of Darwin support

[Paul Pluzhnikov]

On Mon, Aug 10, 2009 at 1:20 PM, Paul Pluzhnikov<ppluzhnikov@google.com> wrote:

> I will try to reproduce the Darwin failure, but I won't get to my Mac
> until later tonight.

I couldn't get GDB to even run the program:

../gdb ../a.out
GNU gdb (GDB) 6.8.50.20090811-cvs
...
(gdb) r
Starting program: /Users/ppluzhnikov/gdb-cvs/build/gdb/a.out
Unable to find Mach task port for process-id 98005: (os/kern) failure (0x5).
 (please check gdb is setgid procmod)
(gdb) q

This even if I make GDB suid-root (I also tried setgid procmod):
ls -l ../gdb
-rwsr-sr-x  1 root  wheel  4075816 Aug 10 20:21 ../gdb

Error 5 is EIO in /usr/include/sys/errno.h

The stack trace for failure (/usr/bin/gdb *is* working):

#0  error (string=0x22127c "Unable to find Mach task port for
process-id %d: %s (0x%lx).\n (please check gdb is setgid procmod)") at
../../src/gdb/utils.c:814
#1  0x000125d6 in darwin_attach_pid (inf=0x63e3f0) at
../../src/gdb/darwin-nat.c:1325
#2  0x0001623e in darwin_ptrace_him (pid=97994) at
../../src/gdb/darwin-nat.c:1454
#3  0x00010204 in fork_inferior (exec_file_arg=0x63dc20
"/Users/ppluzhnikov/gdb-cvs/build/gdb/a.out", allargs=0x63e0c0 "",
env=0x61a0f0, traceme_fun=0x12830 <darwin_ptrace_me>,
init_trace_fun=0x16220 <darwin_ptrace_him>, pre_trace_fun=0x12910
<darwin_pre_ptrace>, shell_file_arg=0x0) at
../../src/gdb/fork-child.c:415
#4  0x000129cc in darwin_create_inferior (ops=0x604470,
exec_file=0x22127c "Unable to find Mach task port for process-id %d:
%s (0x%lx).\n (please check gdb is setgid procmod)", allargs=0x22127c
"Unable to find Mach task port for process-id %d: %s (0x%lx).\n
(please check gdb is setgid procmod)", env=0x22127c, from_tty=1) at
../../src/gdb/darwin-nat.c:1470
#5  0x000fa86c in target_create_inferior (exec_file=0x63dc20
"/Users/ppluzhnikov/gdb-cvs/build/gdb/a.out", args=0x63e0c0 "",
env=0x61a0f0, from_tty=1) at ../../src/gdb/target.c:429
#6  0x000c083b in run_command_1 (args=0x0, from_tty=6545600,
tbreak_at_main=<value temporarily unavailable, due to optimizations>)
at ../../src/gdb/infcmd.c:557
#7  0x0017e695 in execute_command (p=0x600311 "", from_tty=1) at
../../src/gdb/top.c:442
#8  0x000e139e in command_handler (command=0x600310 "") at
../../src/gdb/event-top.c:511
#9  0x000e16f2 in command_line_handler (rl=0x63de40 "??c") at
../../src/gdb/event-top.c:735
#10 0x001b33bd in rl_callback_read_char () at ../../src/readline/callback.c:205
#11 0x000e0c62 in rl_callback_read_char_wrapper (client_data=0x0) at
../../src/gdb/event-top.c:178
#12 0x000dfe25 in handle_file_event (data={ptr = 0x0, integer = 0}) at
../../src/gdb/event-loop.c:812
#13 0x000dfa25 in process_event () at ../../src/gdb/event-loop.c:394
#14 0x000e09bb in gdb_do_one_event (data=0x0) at ../../src/gdb/event-loop.c:459
#15 0x000d9452 in catch_errors (func=0xe0750 <gdb_do_one_event>,
func_args=0x0, errstring=0x26fa00 "", mask=2232956) at
../../src/gdb/exceptions.c:510
#16 0x00049452 in tui_command_loop (data=0x0) at
../../src/gdb/tui/tui-interp.c:153
#17 0x000d9e0c in current_interp_command_loop () at ../../src/gdb/interps.c:291
#18 0x000da592 in captured_command_loop (data=0x0) at ../../src/gdb/main.c:226
#19 0x000d9452 in catch_errors (func=0xda580 <captured_command_loop>,
func_args=0x0, errstring=0x26fa00 "", mask=2232956) at
../../src/gdb/exceptions.c:510
#20 0x000dae0f in captured_main (data=0xbffff8a0) at ../../src/gdb/main.c:902
#21 0x000d9452 in catch_errors (func=0xda5d0 <captured_main>,
func_args=0xbffff8a0, errstring=0x26fa00 "", mask=2232956) at
../../src/gdb/exceptions.c:510
#22 0x000db8bf in gdb_main (args=0x0) at ../../src/gdb/main.c:911
#23 0x000018b4 in main (argc=2232956, argv=0x22127c) at ../../src/gdb/gdb.c:33

Clues? (I don't do any development on Mac, so I am completely clueless.)

Thanks,
-- 
Paul Pluzhnikov

Re: status of Darwin support

[Tristan Gingold]

On Aug 11, 2009, at 7:06 AM, Paul Pluzhnikov wrote:

> On Mon, Aug 10, 2009 at 1:20 PM, Paul Pluzhnikov<ppluzhnikov@google.com 
> > wrote:
>
>> I will try to reproduce the Darwin failure, but I won't get to my Mac
>> until later tonight.
>
> I couldn't get GDB to even run the program:
>
> ../gdb ../a.out
> GNU gdb (GDB) 6.8.50.20090811-cvs
> ...
> (gdb) r
> Starting program: /Users/ppluzhnikov/gdb-cvs/build/gdb/a.out
> Unable to find Mach task port for process-id 98005: (os/kern)  
> failure (0x5).
> (please check gdb is setgid procmod)
> (gdb) q
>
> This even if I make GDB suid-root (I also tried setgid procmod):
> ls -l ../gdb
> -rwsr-sr-x  1 root  wheel  4075816 Aug 10 20:21 ../gdb

IIRC root/wheel doesn't work.  You need setgid procmod only.

Which version of MacOS-X are you using ?

> Error 5 is EIO in /usr/include/sys/errno.h

Except this is not a unix error number but a Mach one :-)

Tristan.

Re: status of Darwin support

[Paul Pluzhnikov]

On Mon, Aug 10, 2009 at 11:59 PM, Tristan Gingold<gingold@adacore.com> wrote:

>> This even if I make GDB suid-root (I also tried setgid procmod):
>> ls -l ../gdb
>> -rwsr-sr-x  1 root  wheel  4075816 Aug 10 20:21 ../gdb
>
> IIRC root/wheel doesn't work.  You need setgid procmod only.

As I said, I did try that; no dice:

ls -l ../gdb
-rwxr-sr-x  1 ppluzhnikov  procmod  4075816 Aug 10 20:21 ../gdb

../gdb -ex run ../a.out
...
Unable to find Mach task port for process-id 98439: (os/kern) failure (0x5).
 (please check gdb is setgid procmod)


> Which version of MacOS-X are you using ?

uname -a
Darwin ppluzhnikov-macbookpro.local 9.7.0 Darwin Kernel Version 9.7.0:
Tue Mar 31 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386

"About this Mac" says:
System Version:	Mac OS X 10.5.7 (9J61)
Kernel Version:	Darwin 9.7.0

>> Error 5 is EIO in /usr/include/sys/errno.h
>
> Except this is not a unix error number but a Mach one :-)

I see. /usr/include/mach/kern_return.h says:

#define KERN_FAILURE                    5
                /* The function could not be performed.  A catch-all.
                 */

Not much help I am afraid :-(

-- 
Paul Pluzhnikov

Re: status of Darwin support

[Tristan Gingold]

On Aug 11, 2009, at 9:13 AM, Paul Pluzhnikov wrote:

> On Mon, Aug 10, 2009 at 11:59 PM, Tristan  
> Gingold<gingold@adacore.com> wrote:
>
>>> This even if I make GDB suid-root (I also tried setgid procmod):
>>> ls -l ../gdb
>>> -rwsr-sr-x  1 root  wheel  4075816 Aug 10 20:21 ../gdb
>>
>> IIRC root/wheel doesn't work.  You need setgid procmod only.
>
> As I said, I did try that; no dice:
>
> ls -l ../gdb
> -rwxr-sr-x  1 ppluzhnikov  procmod  4075816 Aug 10 20:21 ../gdb
>
> ../gdb -ex run ../a.out
> ...
> Unable to find Mach task port for process-id 98439: (os/kern)  
> failure (0x5).
> (please check gdb is setgid procmod)

I have currently no idea about how to explain this failure ;-)

Thanks!
Tristan.

Re: status of Darwin support

[Christian Thalinger]

Paul Pluzhnikov wrote:
> On Mon, Aug 10, 2009 at 11:59 PM, Tristan Gingold<gingold@adacore.com> wrote:
> 
>>> This even if I make GDB suid-root (I also tried setgid procmod):
>>> ls -l ../gdb
>>> -rwsr-sr-x  1 root  wheel  4075816 Aug 10 20:21 ../gdb
>> IIRC root/wheel doesn't work.  You need setgid procmod only.
> 
> As I said, I did try that; no dice:
> 
> ls -l ../gdb
> -rwxr-sr-x  1 ppluzhnikov  procmod  4075816 Aug 10 20:21 ../gdb
> 
> ../gdb -ex run ../a.out
> ...
> Unable to find Mach task port for process-id 98439: (os/kern) failure (0x5).
>  (please check gdb is setgid procmod)

Hmm, it works for me:

$ ls -l ./gdb
-rwxr-sr-x  1 twisti  procmod  4070952 Aug 10 22:24 ./gdb*

-- Christian

Re: status of Darwin support

[Christian Thalinger]

Paul Pluzhnikov wrote:
> On Mon, Aug 10, 2009 at 11:32 AM, Tom Tromey<tromey@redhat.com> wrote:
> 
>>>>>>> "Twisti" == Christian Thalinger <Christian.Thalinger@Sun.COM> writes:
>> Twisti> objfiles.c:792: internal-error: qsort_cmp: Assertion `obj_section_endaddr (sect1) <= sect2_addr' failed.
>> Twisti> A problem internal to GDB has been detected,
>> Twisti> further debugging may prove unreliable.
>>
>> This is a recent regression.  Paul Pluzhnikov posted a patch to fix this
>> crash on Linux, but I don't know whether the patch will fix Darwin.
>> Could you give it a try?  (The patch is approved so presumably he will
>> be checking it in soon...)
> 
> I've just committed the patch.
> 
> I will try to reproduce the Darwin failure, but I won't get to my Mac
> until later tonight.

I couldn't get the changes yesterday (CVS seems to have some delay?) but
I have them now.

The assert you removed was at line 801, but my assert is at 792.  And,
obviously, it still asserts.  These are the values:

(gdb) r
Starting program:
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/gamma
0x4fd3 <= 0x7040
0x70d1 <= 0xc9b7
0x5ffd <= 0x7040
0x6015 <= 0x7040
0x6034 <= 0x7040
0x6074 <= 0x7040
0x7014 <= 0x7040
0x4fd3 <= 0x7040
0x4fd3 <= 0x7040
0x6074 <= 0x7040
0x6015 <= 0x7040
0x6eee <= 0x7040
0x5ffd <= 0x6000
0x6015 <= 0x6018
0x6034 <= 0x6034
0x6074 <= 0x7000
0x4fd3 <= 0x1bc2
objfiles.c:793: internal-error: qsort_cmp: Assertion
`obj_section_endaddr (sect1) <= sect2_addr' failed.

I'm not sure that helps...

-- Christian

Re: status of Darwin support

[Paul Pluzhnikov]

On Tue, Aug 11, 2009 at 1:27 AM, Christian Thalinger
<Christian.Thalinger@sun.com> wrote:

> The assert you removed was at line 801, but my assert is at 792.  And,
> obviously, it still asserts.  These are the values:

Indeed, this is a different assert from the one that fired on Linux,
sorry I missed that.

> (gdb) r
> Starting program:
> /Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/gamma

I assume these are from debug prints of (section addr? or endaddr?) you've
added? They look like possibly non-relocated section addresses.

> 0x4fd3 <= 0x7040
> 0x70d1 <= 0xc9b7
> 0x5ffd <= 0x7040
> 0x6015 <= 0x7040
> 0x6034 <= 0x7040
> 0x6074 <= 0x7040
> 0x7014 <= 0x7040
> 0x4fd3 <= 0x7040
> 0x4fd3 <= 0x7040
> 0x6074 <= 0x7040
> 0x6015 <= 0x7040
> 0x6eee <= 0x7040
> 0x5ffd <= 0x6000
> 0x6015 <= 0x6018
> 0x6034 <= 0x6034
> 0x6074 <= 0x7000
> 0x4fd3 <= 0x1bc2
> objfiles.c:793: internal-error: qsort_cmp: Assertion
> `obj_section_endaddr (sect1) <= sect2_addr' failed.
>
> I'm not sure that helps...

Could you run gdb under /usr/bin/gdb, like this:

/usr/bin/gdb --args ./gdb -nx
/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/gamma
(top-gdb) break error
(top-gdb) run
(gdb) run

### You may hit error several times before the 'qsort_cmp' fires.
### Once it does, go up to qsort_cmp level and (at the (top-gdb) prompt):

  print *sect1->the_bfd_section
  print *sect1->objfile
  print *sect2->the_bfd_section
  print *sect2->objfile

Thanks,
--
Paul Pluzhnikov

Re: status of Darwin support

[Christian Thalinger]

Paul Pluzhnikov wrote:
>> (gdb) r
>> Starting program:
>> /Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/gamma
> 
> I assume these are from debug prints of (section addr? or endaddr?) you've
> added? They look like possibly non-relocated section addresses.

Yes, the same values as the assert compares.

> Could you run gdb under /usr/bin/gdb, like this:
> 
> /usr/bin/gdb --args ./gdb -nx
> /Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/gamma
> (top-gdb) break error
> (top-gdb) run
> (gdb) run

I tried that before, but then I get the:

Unable to find Mach task port for process-id 90603: (os/kern) failure (0x5).
 (please check gdb is setgid procmod)

again.  I just tried to run it as root, then it runs but the break does
not work.  I'm confused...

-- Christian

Re: status of Darwin support

[Paul Pluzhnikov]

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

>> /usr/bin/gdb --args ./gdb -nx
>> /Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/gamma
>> (top-gdb) break error
>> (top-gdb) run
>> (gdb) run
>
> I tried that before, but then I get the:
>
> Unable to find Mach task port for process-id 90603: (os/kern) failure (0x5).
>   (please check gdb is setgid procmod)

Ah, that makes sense: the inferior GDB can't be suid.

> again.  I just tried to run it as root, then it runs but the break does
> not work.  I'm confused...

But (eventually) you should get to SIGABRT, which is just as good a place
to execute prints. Do you?

Thanks,
-- 
Paul Pluzhnikov

Re: status of Darwin support

[Christian Thalinger]

Christian Thalinger wrote:
> I tried that before, but then I get the:
> 
> Unable to find Mach task port for process-id 90603: (os/kern) failure (0x5).
>  (please check gdb is setgid procmod)
> 
> again.  I just tried to run it as root, then it runs but the break does
> not work.  I'm confused...

I was able to attach to the process.  Here is the data:

(gdb) info locals
sect1 = (const struct obj_section *) 0x860430
sect2 = (const struct obj_section *) 0x867e30
sect1_addr = 7008
sect2_addr = 7106
__PRETTY_FUNCTION__ = "qsort_cmp"
(gdb) p *sect1->the_bfd_section
$1 = {
  name = 0x85fa34 ".text",
  id = 25,
  index = 0,
  next = 0x8614c4,
  prev = 0x0,
  flags = 283,
  user_set_vma = 0,
  linker_mark = 0,
  linker_has_input = 0,
  gc_mark = 0,
  segment_mark = 0,
  sec_info_type = 0,
  use_rela_p = 0,
  has_tls_reloc = 0,
  has_tls_get_addr_call = 0,
  has_gp_reloc = 0,
  need_finalize_relax = 0,
  reloc_done = 0,
  vma = 7008,
  lma = 7008,
  size = 13427,
  rawsize = 0,
  relax = 0x0,
  relax_count = 0,
  output_offset = 0,
  output_section = 0x0,
  alignment_power = 2,
  relocation = 0x0,
  orelocation = 0x0,
  reloc_count = 0,
  filepos = 2912,
  rel_filepos = 0,
  line_filepos = 0,
  userdata = 0x0,
  contents = 0x0,
  lineno = 0x0,
  lineno_count = 0,
  entsize = 0,
  kept_section = 0x0,
  moving_line_filepos = 0,
  target_index = 0,
  used_by_bfd = 0x0,
  constructor_chain = 0x0,
  owner = 0x63e0e0,
  symbol = 0x85fa3c,
  symbol_ptr_ptr = 0x8614a8,
  map_head = {
    link_order = 0x0,
    s = 0x0
  },
  map_tail = {
    link_order = 0x0,
    s = 0x0
  }
}
(gdb) p *sect1->objfile
$2 = {
  next = 0x71e000,
  name = 0x63dd70
"/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/gamma",
  flags = 1,
  symtabs = 0x0,
  psymtabs = 0x0,
  psymtabs_addrmap = 0x0,
  free_psymtabs = 0x0,
  obfd = 0x63e0e0,
  gdbarch = 0x85d408,
  mtime = 1249556492,
  objfile_obstack = {
    chunk_size = 4072,
    chunk = 0x865e00,
    object_base = 0x865ef8 "",
    next_free = 0x865ef8 "",
    chunk_limit = 0x866de8 "",
    temp = 0,
    alignment_mask = 3,
    chunkfun = 0x183a90 <xmalloc>,
    freefun = 0x182010 <xfree>,
    extra_arg = 0x0,
    use_extra_arg = 0,
    maybe_empty_object = 0,
    alloc_failed = 0
  },
  psymbol_cache = 0x63e010,
  macro_cache = 0x63e190,
  demangled_names_hash = 0x63e350,
  global_psymbols = {
    list = 0x0,
    next = 0x0,
    size = 0
  },
  static_psymbols = {
    list = 0x0,
    next = 0x0,
    size = 0
  },
  msymbols = 0x8608e4,
  minimal_symbol_count = 64,
  msymbol_hash = {0x0 <repeats 30 times>, 0x86090c, 0x0, 0x0, 0x0, 0x0,
0x0, 0x860e84, 0x0 <repeats 28 times>, 0x8609d4, 0x0, 0x0, 0x0, 0x0,
0x860efc, 0x0, 0x0, 0x860ed4, 0x0 <repeats 22 times>, 0x860e0c, 0x0
<repeats 29 times>, 0x861014, 0x860f74, 0x0 <repeats 17 times>,
0x860fec, 0x0 <repeats 16 times>, 0x860c54, 0x0 <repeats 11 times>,
0x8610dc, 0x0 <repeats 38 times>, 0x8610b4, 0x0 <repeats 30 times>,
0x860f9c, 0x0 <repeats 42 times>, 0x860a24, 0x0, 0x860de4, 0x0 <repeats
12 times>, 0x860934, 0x0 <repeats 41 times>, 0x860984, 0x0 <repeats 45
times>, 0x86103c, 0x0 <repeats 11 times>, 0x861154, 0x0 <repeats 30
times>, 0x860c04, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x860bdc, 0x0
<repeats 19 times>...},
  msymbol_demangled_hash = {0x0 <repeats 2039 times>},
  sf = 0x29b460,
  ei = {
    entry_point = 7008
  },
  deprecated_sym_stab_info = 0x0,
  deprecated_sym_private = 0x0,
  data = 0x63de70,
  num_data = 8,
  section_offsets = 0x860484,
  num_sections = 9,
  sect_index_text = 0,
  sect_index_data = -1,
  sect_index_bss = -1,
  sect_index_rodata = -1,
  sections = 0x860430,
  sections_end = 0x860484,
  separate_debug_objfile = 0x0,
  separate_debug_objfile_backlink = 0x0,
  stats = {
    n_minsyms = 64,
    n_psyms = 0,
    n_syms = 0,
    n_stabs = 0,
    n_types = 0,
    sz_strtab = 0
  },
  cp_namespace_symtab = 0x0
}
(gdb) p *sect2->the_bfd_section
$3 = {
  name = 0x8674d4 ".text",
  id = 34,
  index = 0,
  next = 0x868ec4,
  prev = 0x0,
  flags = 311,
  user_set_vma = 0,
  linker_mark = 0,
  linker_has_input = 0,
  gc_mark = 0,
  segment_mark = 0,
  sec_info_type = 0,
  use_rela_p = 0,
  has_tls_reloc = 0,
  has_tls_get_addr_call = 0,
  has_gp_reloc = 0,
  need_finalize_relax = 0,
  reloc_done = 0,
  vma = 0,
  lma = 0,
  size = 13329,
  rawsize = 0,
  relax = 0x0,
  relax_count = 0,
  output_offset = 0,
  output_section = 0x868e14,
  alignment_power = 0,
  relocation = 0x0,
  orelocation = 0x0,
  reloc_count = 651,
  filepos = 1344,
  rel_filepos = 53004,
  line_filepos = 0,
  userdata = 0x0,
  contents = 0x0,
  lineno = 0x0,
  lineno_count = 0,
  entsize = 0,
  kept_section = 0x0,
  moving_line_filepos = 0,
  target_index = 0,
  used_by_bfd = 0x0,
  constructor_chain = 0x0,
  owner = 0x63e400,
  symbol = 0x8674dc,
  symbol_ptr_ptr = 0x868ea8,
  map_head = {
    link_order = 0x0,
    s = 0x0
  },
  map_tail = {
    link_order = 0x0,
    s = 0x0
  }
}
(gdb) p *sect2->objfile
$4 = {
  next = 0x0,
  name = 0x63e590
"/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/launcher.o",

  flags = 1,
  symtabs = 0x0,
  psymtabs = 0x8799c8,
  psymtabs_addrmap = 0x879a54,
  free_psymtabs = 0x0,
  obfd = 0x63e400,
  gdbarch = 0x85d408,
  mtime = 1248941544,
  objfile_obstack = {
    chunk_size = 4072,
    chunk = 0x879400,
    object_base = 0x879a7c "",
    next_free = 0x879a7c "",
    chunk_limit = 0x87a3e8 "",
    temp = 0,
    alignment_mask = 3,
    chunkfun = 0x183a90 <xmalloc>,
    freefun = 0x182010 <xfree>,
    extra_arg = 0x0,
    use_extra_arg = 0,
    maybe_empty_object = 0,
    alloc_failed = 0
  },
  psymbol_cache = 0x63e4d0,
  macro_cache = 0x63e530,
  demangled_names_hash = 0x63e6b0,
  global_psymbols = {
    list = 0x63eb70,
    next = 0x63ebac,
    size = 102
  },
  static_psymbols = {
    list = 0x82d000,
    next = 0x82d218,
    size = 204
  },
  msymbols = 0x867e08,
  minimal_symbol_count = 0,
  msymbol_hash = {0x0 <repeats 2039 times>},
  msymbol_demangled_hash = {0x0 <repeats 2039 times>},
  sf = 0x29b460,
  ei = {
    entry_point = 4294967295
  },
  deprecated_sym_stab_info = 0x0,
  deprecated_sym_private = 0x0,
  data = 0x63e390,
  num_data = 8,
  section_offsets = 0x867e78,
  num_sections = 17,
  sect_index_text = 0,
  sect_index_data = -1,
  sect_index_bss = -1,
  sect_index_rodata = -1,
  sections = 0x867e30,
  sections_end = 0x867e78,
  separate_debug_objfile = 0x0,
  separate_debug_objfile_backlink = 0x0,
  stats = {
    n_minsyms = 0,
    n_psyms = 149,
    n_syms = 0,
    n_stabs = 0,
    n_types = 0,
    sz_strtab = 0
  },
  cp_namespace_symtab = 0x0
}
(gdb)

-- Christian

Re: status of Darwin support

[Paul Pluzhnikov]

On Tue, Aug 11, 2009 at 9:49 AM, Christian
Thalinger<Christian.Thalinger@sun.com> wrote:

> I was able to attach to the process. Here is the data:
...
> (gdb) p *sect2->objfile
> $4 = {
>  name = 0x63e590 "/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/launcher.o",

This is possibly unrelocated objfile. What does

  print sect2->objfile->section_offsets[0]@17

say?

Thanks,
-- 
Paul Pluzhnikov

Re: status of Darwin support

[Christian Thalinger]

Paul Pluzhnikov wrote:
> On Tue, Aug 11, 2009 at 9:49 AM, Christian
> Thalinger<Christian.Thalinger@sun.com> wrote:
> 
>> I was able to attach to the process. Here is the data:
> ...
>> (gdb) p *sect2->objfile
>> $4 = {
>>  name = 0x63e590 "/Users/twisti/bsd-port/hotspot/build/bsd/bsd_i486_compiler2/jvmg/launcher.o",
> 
> This is possibly unrelocated objfile. What does
> 
>   print sect2->objfile->section_offsets[0]@17
> 
> say?

(gdb) p sect2->objfile->section_offsets[0]@17
$5 = {{
    offsets = {7106}
  }, {
    offsets = {0}
  } <repeats 11 times>, {
    offsets = {4294940264}
  }, {
    offsets = {4294944662}
  }, {
    offsets = {4294944325}
  }, {
    offsets = {0}
  }, {
    offsets = {0}
  }}

-- Christian

Re: status of Darwin support

[Paul Pluzhnikov]

On Tue, Aug 11, 2009 at 10:25 AM, Christian
Thalinger<Christian.Thalinger@sun.com> wrote:

> (gdb) p sect2->objfile->section_offsets[0]@17
> $5 = {{offsets = {7106}}, {offsets = {0}} <repeats 11 times>, {
>    offsets = {4294940264}}, {offsets = {4294944662}}, {offsets =
>      {4294944325}}, {offsets = {0}}, {offsets = {0}}}

Hmm, not all zeros ...
It would have helped me a lot if I know what values are expected here :-(

I think I'll have to get gdb-cvs working before I can debug this some more.

Searching google for the "Unable to find Mach task port for process-id"
shows several threads like this:
http://lists.apple.com/archives/Xcode-users/2007/Dec/msg00777.html

So I'll probably have to find out the differences between GDB in Xcode 2.5
and 3.0. I suspect there is some magic syscall one has to perform on Leopard.

BTW, what OS are you on?

Thanks,
-- 
Paul Pluzhnikov

Re: status of Darwin support

[Christian Thalinger]

Paul Pluzhnikov wrote:
> On Tue, Aug 11, 2009 at 10:25 AM, Christian
> Thalinger<Christian.Thalinger@sun.com> wrote:
> 
>> (gdb) p sect2->objfile->section_offsets[0]@17
>> $5 = {{offsets = {7106}}, {offsets = {0}} <repeats 11 times>, {
>>    offsets = {4294940264}}, {offsets = {4294944662}}, {offsets =
>>      {4294944325}}, {offsets = {0}}, {offsets = {0}}}
> 
> Hmm, not all zeros ...
> It would have helped me a lot if I know what values are expected here :-(
> 
> I think I'll have to get gdb-cvs working before I can debug this some more.
> 
> Searching google for the "Unable to find Mach task port for process-id"
> shows several threads like this:
> http://lists.apple.com/archives/Xcode-users/2007/Dec/msg00777.html
> 
> So I'll probably have to find out the differences between GDB in Xcode 2.5
> and 3.0. I suspect there is some magic syscall one has to perform on Leopard.
> 
> BTW, what OS are you on?

It's 10.5.8:

$ uname -a
Darwin macbook 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01
PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

but it also worked on 10.5.7.  The only thing that pops into my mind is
that my user is also an admin...

-- Christian

Re: status of Darwin support

[Paul Pluzhnikov]

On Tue, Aug 11, 2009 at 10:38 AM, Paul Pluzhnikov<ppluzhnikov@google.com> wrote:

> So I'll probably have to find out the differences between GDB in Xcode 2.5
> and 3.0. I suspect there is some magic syscall one has to perform on Leopard.

Update:

Searching for "macos task_for_pid" led me to
http://books.google.com/books?id=H47LLszkhPQC&pg=PA297&lpg=PA297&dq=macos+task_for_pid&source=bl&ots=c3byoP5Xsg&sig=Mis8Sr-opekOlj8QIUp_j7yvk50&hl=en&ei=QFmCSu2ALsuLtgeA0azHCg&sa=X&oi=book_result&ct=result&resnum=9#v=onepage&q=&f=false

which explains why 'chgrp procmod gdb && chmod g+s gdb' is no longer
necessary, nor sufficient.

[I find it astonishing that even armed with above answer I can't find the
same answer on apple.com (so I could cut/paste it).]

I *am* in the "admin" group, but not in "procmod" group. I can't figure
out how to add myself to "procmod" either :-(

But no matter: I can run the gdb-cvs as root, and I do see the assert when
I do "./gdb ./gdb".

I'll try to debug this tonight.

Thanks,
-- 
Paul Pluzhnikov

Re: status of Darwin support

[Christian Thalinger]

Paul Pluzhnikov wrote:
> I *am* in the "admin" group, but not in "procmod" group. I can't figure
> out how to add myself to "procmod" either :-(

I'm not in the procmod group either... very strange.

> 
> But no matter: I can run the gdb-cvs as root, and I do see the assert when
> I do "./gdb ./gdb".
> 
> I'll try to debug this tonight.

Thanks.

-- Christian

[patch] [new testcase] Regression on qsort_cmp [Re: status of Darwin support]

[Jan Kratochvil]

On Tue, 11 Aug 2009 10:27:55 +0200, Christian Thalinger wrote:
> objfiles.c:793: internal-error: qsort_cmp: Assertion `obj_section_endaddr (sect1) <= sect2_addr' failed.

Getting randomly this error or:
objfiles.c:817: internal-error: preferred_obj_section: Assertion `(a->objfile->separate_debug_objfile == b->objfile) || (b->objfile->separate_debug_objfile == a->objfile)' failed.

which have both the same reason that solibs overlap in VMAs.

IMO these assertions are right and GDB should rather refuse to load
overlapping sections.  Still they may(?) be required for overlays, actively in
use for IBM Cell (as I was considering overlays as obsolete before myself).

First bugreport of this crash by the courtesy of Mamoru Tasaka in RH Bug 515434.

Requesting approval for the testcase check-in.
Tested on {x86_64,i686}-fedorarawhide-linux-gnu:
FAIL: gdb.base/solib-overlap.exp: 0x40000000: attach (GDB internal error)
FAIL: gdb.base/solib-overlap.exp: 0x50000000: attach (GDB internal error)


Thanks,
Jan


2009-08-25  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* gdb.base/solib-overlap.exp, gdb.base/solib-overlap-lib.c,
	gdb.base/solib-overlap-main.c: New.

--- /dev/null
+++ b/gdb/testsuite/gdb.base/solib-overlap-lib.c
@@ -0,0 +1,27 @@
+/* Copyright 2009 Free Software Foundation, Inc.
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+   Contributed by Jan Kratochvil <jan.kratochvil@redhat.com>.  */
+
+void
+libsym (void)
+{
+}
+
+#ifdef SYMB
+void
+libsymb (void)
+{
+}
+#endif
--- /dev/null
+++ b/gdb/testsuite/gdb.base/solib-overlap-main.c
@@ -0,0 +1,25 @@
+/* Copyright 2009 Free Software Foundation, Inc.
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+   Contributed by Jan Kratochvil <jan.kratochvil@redhat.com>.  */
+
+#include <unistd.h>
+
+int
+main (void)
+{
+  sleep (60);
+
+  return 1;
+}
--- /dev/null
+++ b/gdb/testsuite/gdb.base/solib-overlap.exp
@@ -0,0 +1,135 @@
+# Copyright 2009 Free Software Foundation, Inc.
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+#
+# Contributed by Jan Kratochvil <jan.kratochvil@redhat.com>.
+
+# Test GDB can cope with two libraries loaded with overlapping VMA ranges.
+# Prelink libraries first so they can be loaded and their native address.
+# In such case `struct linkmap'.l_addr will be zero.  Provide different
+# unprelinked library files on the disk which have zero-based VMAs.  These
+# different files should have their .dynamic section at a different offset in
+# page size so that we get for
+#   warning: .dynamic section for "..." is not at the expected address
+# the reason
+#   (wrong library or version mismatch?)
+# and not:
+#   difference appears to be caused by prelink, adjusting expectations
+# In such case both disk libraries will be loaded at VMAs starting at zero.
+
+if [skip_shlib_tests] {
+    return 0
+}
+
+# Are we on a target board?  It is required for attaching to a process.
+if [is_remote target] {
+    return 0
+}
+
+# Library file.
+set libname "solib-overlap-lib"
+set srcfile_lib ${srcdir}/${subdir}/${libname}.c
+# Binary file.
+set testfile "solib-overlap-main"
+set srcfile ${srcdir}/${subdir}/${testfile}.c
+
+# Base addresses for `prelink -r' which should be compatible with both -m32 and
+# -m64 targets.  If it clashes with system prelinked libraries it would give
+# false PASS.
+# Prelink first lib1 at 0x40000000 and lib2 at 0x41000000.
+# During second pass try lib1 at 0x50000000 and lib2 at 0x51000000.
+foreach prelink_lib1 {0x40000000 0x50000000} {
+    set prelink_lib2 [format "0x%x" [expr $prelink_lib1 + 0x01000000]]
+
+    set old_prefix $pf_prefix
+    lappend pf_prefix "$prelink_lib1:"
+
+    # Library file.
+    set binfile_lib1 ${objdir}/${subdir}/${libname}1-${prelink_lib1}.so
+    set binfile_lib2 ${objdir}/${subdir}/${libname}2-${prelink_lib1}.so
+    set lib_flags {debug}
+    # Binary file.
+    set binfile_base ${testfile}-${prelink_lib1}
+    set binfile ${objdir}/${subdir}/${binfile_base}
+    set bin_flags [list debug shlib=${binfile_lib1} shlib=${binfile_lib2}]
+    set escapedbinfile  [string_to_regexp ${binfile}]
+
+    if { [gdb_compile_shlib ${srcfile_lib} ${binfile_lib1} $lib_flags] != ""
+	 || [gdb_compile_shlib ${srcfile_lib} ${binfile_lib2} $lib_flags] != ""
+	 || [gdb_compile ${srcfile} ${binfile} executable $bin_flags] != "" } {
+	untested "Could not compile ${binfile_lib1}, ${binfile_lib2} or ${binfile}."
+	return -1
+    }
+
+    if {[catch "system \"prelink -N -r ${prelink_lib1} ${binfile_lib1}\""] != 0
+	|| [catch "system \"prelink -N -r ${prelink_lib2} ${binfile_lib2}\""] != 0} {
+	# Maybe we don't have prelink.
+	untested "Could not prelink ${binfile_lib1} or ${binfile_lib2}."
+	return -1
+    }
+
+    # Start the program running and then wait for a bit, to be sure
+    # that it can be attached to.
+
+    set testpid [eval exec $binfile &]
+    sleep 2
+    if { [istarget "*-*-cygwin*"] } {
+	# testpid is the Cygwin PID, GDB uses the Windows PID, which might be
+	# different due to the way fork/exec works.
+	set testpid [ exec ps -e | gawk "{ if (\$1 == $testpid) print \$4; }" ]
+    }
+
+    remote_exec build "mv -f ${binfile_lib1} ${binfile_lib1}-running"
+    remote_exec build "mv -f ${binfile_lib2} ${binfile_lib2}-running"
+
+    # Provide another exported function name to cause different sizes of sections.
+    lappend lib_flags additional_flags=-DSYMB
+
+    if { [gdb_compile_shlib ${srcfile_lib} ${binfile_lib1} $lib_flags] != ""
+	 || [gdb_compile_shlib ${srcfile_lib} ${binfile_lib2} $lib_flags] != ""} {
+	untested "Could not recompile ${binfile_lib1} or ${binfile_lib2}."
+	remote_exec build "kill -9 ${testpid}"
+	return -1
+    }
+
+    clean_restart ${binfile_base}
+    # This testcase currently does not support remote targets.
+    # gdb_load_shlibs ${binfile_lib1} ${binfile_lib2}
+
+    # Here we should get:
+    # warning: .dynamic section for ".../solib-overlap-lib1.so" is not at the expected address (wrong library or version mismatch?)
+    # warning: .dynamic section for ".../solib-overlap-lib2.so" is not at the expected address (wrong library or version mismatch?)
+
+    set test attach
+    gdb_test_multiple "attach $testpid" $test {
+	-re "Attaching to program.*`?$escapedbinfile'?, process $testpid.*$gdb_prompt $" {
+	    pass $test
+	}
+	-re "Attaching to program.*`?$escapedbinfile\.exe'?, process $testpid.*\[Switching to thread $testpid\..*\].*$gdb_prompt $" {
+	    # Response expected on Cygwin
+	    pass $test
+	}
+    }
+
+    # Detach the process.
+
+    gdb_test "detach" "Detaching from program: .*$escapedbinfile, process $testpid"
+
+    # Wait a bit for gdb to finish detaching
+
+    sleep 5
+
+    remote_exec build "kill -9 ${testpid}"
+
+    set pf_prefix $old_prefix
+}

Re: Regression on qsort_cmp [Re: status of Darwin support]

[Tristan Gingold]

On Aug 25, 2009, at 10:46 AM, Jan Kratochvil wrote:

> On Tue, 11 Aug 2009 10:27:55 +0200, Christian Thalinger wrote:
>> objfiles.c:793: internal-error: qsort_cmp: Assertion  
>> `obj_section_endaddr (sect1) <= sect2_addr' failed.
>
> Getting randomly this error or:
> objfiles.c:817: internal-error: preferred_obj_section: Assertion `(a- 
> >objfile->separate_debug_objfile == b->objfile) || (b->objfile- 
> >separate_debug_objfile == a->objfile)' failed.
>
> which have both the same reason that solibs overlap in VMAs.
>
> IMO these assertions are right and GDB should rather refuse to load
> overlapping sections.  Still they may(?) be required for overlays,  
> actively in
> use for IBM Cell (as I was considering overlays as obsolete before  
> myself).

Still late in the game, but I think I now understand the issue:

On Darwin, debug info are kept in object files.  To make gdb work, we  
load the executable but also the
symbols from its object files.  In update_section map we don't make  
the difference between these two.

IMHO we should slightly extend the notion of separate_debug_objfile so  
that Darwin could use it and
then modify update_section_map to correctly deals with that.

Instead of allowing one separate debug file per objfile, we should  
allow many debug files (using a linked
list) (The question of allowing one level or several levels is still  
open).

The section map would flatten the tree and maybe fill the holes in  
separate debug files using the father.

Well, that's the design I have in my mind...

Tristan.

Re: Regression on qsort_cmp [Re: status of Darwin support]

[Jack Howarth]

On Tue, Sep 08, 2009 at 11:31:16AM +0200, Tristan Gingold wrote:
>
> On Aug 25, 2009, at 10:46 AM, Jan Kratochvil wrote:
>
>> On Tue, 11 Aug 2009 10:27:55 +0200, Christian Thalinger wrote:
>>> objfiles.c:793: internal-error: qsort_cmp: Assertion  
>>> `obj_section_endaddr (sect1) <= sect2_addr' failed.
>>
>> Getting randomly this error or:
>> objfiles.c:817: internal-error: preferred_obj_section: Assertion `(a- 
>> >objfile->separate_debug_objfile == b->objfile) || (b->objfile- 
>> >separate_debug_objfile == a->objfile)' failed.
>>
>> which have both the same reason that solibs overlap in VMAs.
>>
>> IMO these assertions are right and GDB should rather refuse to load
>> overlapping sections.  Still they may(?) be required for overlays,  
>> actively in
>> use for IBM Cell (as I was considering overlays as obsolete before  
>> myself).
>
> Still late in the game, but I think I now understand the issue:
>
> On Darwin, debug info are kept in object files.  To make gdb work, we  
> load the executable but also the
> symbols from its object files.  In update_section map we don't make the 
> difference between these two.
>
> IMHO we should slightly extend the notion of separate_debug_objfile so  
> that Darwin could use it and
> then modify update_section_map to correctly deals with that.
>
> Instead of allowing one separate debug file per objfile, we should allow 
> many debug files (using a linked
> list) (The question of allowing one level or several levels is still  
> open).
>
> The section map would flatten the tree and maybe fill the holes in  
> separate debug files using the father.
>
> Well, that's the design I have in my mind...
>
> Tristan.

Tristan,
   When you have any test patches for this, I would be happy to
try them on x86_64-apple-darwin10 and i686-apple-darwin10 if you
don't have Snow Leopard installed yet.
                   Jack