Re: Unbreaking gdb on Solaris post-multitarget [PR 25939]

Rainer Orth
2020-06-19T12:36:10Z

Hi Pedro,

> On 6/18/20 3:55 PM, Pedro Alves via Gdb-patches wrote:
>> On 6/17/20 3:45 PM, Rainer Orth wrote:
>>> [Thread debugging using libthread_db enabled]
>>> [New Thread 1 (LWP 1)]
>>> Breakpoint 1 at 0x401036: file hello.c, line 6.
>>> bottom-gdb.gdb:3: Error in sourced command file:
>>> procfs: couldn't find pid 0 in procinfo list.
>>
>> I see what this is. This is procfs_target::wait relying on
>> inferior_ptid. Since the multi-target series, inferior_ptid
>> is null_ptid before we call target_wait:
>>
>> static ptid_t
>> do_target_wait_1 (inferior *inf, ptid_t ptid,
>> target_waitstatus *status, int options)
>> {
>> ptid_t event_ptid;
>> struct thread_info *tp;
>>
>> /* We know that we are looking for an event in the target of inferior
>> INF, but we don't know which thread the event might come from. As
>> such we want to make sure that INFERIOR_PTID is reset so that none of
>> the wait code relies on it - doing so is always a mistake. */
>> switch_to_inferior_no_thread (inf);
>>
>>
>> I'm working on a patch.

I'd identified procfs_target::wait as the cause of the
find_procinfo_or_die call with pid = 0 by adding a sleep call in the
latter and attaching gdb to look where I am, but hadn't gotten further yet.

> Here it is. This works for me on a Solaris 11.3 (virtual and slow...) machine.

I'd meant to suggest trying gcc211 in the GCC compile farm, but the
machine was quite busy when I looked/tried, lacked some vital software
(bison, patch, makeinfo, make only as gmake, gcc 5.5.0 only which may or
may not work). I've built those myself and managed a gdb build, too,
but the experience wasn't too pretty: not what I'd want to work with as
a developer on a foreign platform meant to support gcc/gdb/binutils...

> Debugging GDB itself works for me, and I've checked that the gdb.base/break.exp
> testcase passes cleanly, at least.
>
> Your push_target fix is still necessary, FAOD.

Should I push it as is (with an appropriate description, of course) or
would the code change need a comment, too?

> Could you give it a try?

I did so now, both on amd64-pc-solaris2.11 (Solaris 11.4), and
sparcv9-sun-solaris2.11 (Solaris 11.3, gcc211 above).

gdb basically works again, but compared to the pre-multi-target results
I have still a considerable number of regressions:

before:

# of expected passes 62928
# of unexpected failures 1841
# of unexpected successes 4
# of expected failures 49
# of unknown successes 6

now:

# of expected passes 63768
# of unexpected failures 2411
# of expected failures 52
# of unknown successes 1

Of course there's months of gdb development between the two, but e.g. I
see

268 /vol/src/gnu/gdb/hg/master/local/gdb/thread.c:336: internal-error: thread_info::thread_info(inferior*, ptid_t): Assertion `inf_ != NULL' failed.
119 /vol/src/gnu/gdb/hg/master/local/gdb/thread.c:86: internal-error: thread_info* inferior_thread(): Assertion `tp' failed.
88 /vol/src/gnu/gdb/hg/master/local/gdb/inline-frame.c:384: internal-error: void skip_inline_frames(thread_info*, bpstat): Assertion `find_inline_frame_stacore LWP 1 In: ' failed.

compared to previous

487 /vol/src/gnu/gdb/hg/master/reghunt/gdb/thread.c:93: internal-error: thread_info* inferior_thread(): Assertion `tp' failed.
72 /vol/src/gnu/gdb/hg/master/reghunt/gdb/inline-frame.c:367: internal-error: void skip_inline_frames(thread_info*, bpstat): Assertion `find_inline_frame_state (thread) == NULL' failed.

Some of those are definitively regressions, although it's difficult to
say with the flaky nature of several tests on Solaris.

Whatever the case, it looks like I have months of work ahead ;-)

Thanks a lot for fixing this.

Rainer

--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University