Re: [PATCH v6 3/4] Share fork_inferior et al with gdbserver

Sergio Durigan Junior
2017-06-07T21:00:27Z

On Wednesday, June 07 2017, Pedro Alves wrote:

> On 05/31/2017 04:43 AM, Sergio Durigan Junior wrote:
>>
>>>> >> index 4ea7913..8aa85db 100644
>>>> >> --- a/gdb/gdbserver/configure.ac
>>>> >> +++ b/gdb/gdbserver/configure.ac
>>>> >> @@ -462,7 +462,9 @@ esac],
>>>> >>
>>>> >> if $want_ipa ; then
>>>> >> if $have_ipa ; then
>>>> >> - IPA_DEPFILES="$ipa_obj"
>>>> >> + # Needed because safe_strerror's definition is host-dependent
>>> >
>>> > Why do we end up needing safe_strerror in the IPA in the first place?
>> This is needed because I moved the definition of
>> trace_start_error_with_name from the old gdb/fork-child.c to
>> common/common-utils.c. This function which uses safe_strerror, and
>> common/common-utils.c is compiled by IPA.
>>
>> An option would be to keep these trace_start_error.* functions in
>> nat/fork-inferior.c, but I think it is more logical to keep them on
>> common-utils.c.
>
> I'd rather not add them to the IPA. The least unnecessary code
> is included in that library the better, because it is injected
> into the target process. So keeping them in fork-inferior.c
> sounds better.

OK, fair enough.

>> Now, I can obviously expand the comment if that's what you meant.
>>
>>>> >> + strerror_obj="`echo $srv_host_obs | sed 's/\(.*-strerror\)\.o/\1-ipa.o/'`"
>>>> >> + IPA_DEPFILES="$ipa_obj $strerror_obj"
>>>> >> extra_libraries="$extra_libraries libinproctrace.so"
>>>> >> else
>>>> >> AC_MSG_ERROR([inprocess agent not supported for this target])
>>> >
>>> >
>>> >
>>>> >> -#if defined(__UCLIBC__) && defined(HAS_NOMMU)
>>>> >> - pid = vfork ();
>>> >
>>> > Does fork_inferior end up always using vfork on no-MMU
>>> > ports somehow?
>> Sorry, I am not sure. How would I go about finding that?
>
> I'm not sure either. configure.ac for anything fork related?
> Look at git blame history around those lines, see what other
> bits were touched at the same time? gdbserver clearly cares about
> being built for no-MMU ports, so the new code must too. We can't
> just delete that support without an alternative.

As explained earlier in private, I'm sorry for the confusion. I totally
misunderstood your question; I thought you were suggesting to *remove*
the defines, but you actually wants to know why they were removed from
the code... Obviously!

Well, as I said, I totally agree that they should be kept and I will put
them back.

--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible