Re: [PATCH 2/6] Don't reset errno/bfd_error on 'throw_perror_with_name'

Pedro Alves
2020-02-28T20:06:12Z

On 2/28/20 3:29 PM, Tom Tromey wrote:
>>>>>> "Sergio" == Sergio Durigan Junior <sergiodj@redhat.com> writes:
>
> Sergio> Since this hunk may be a bit controversial, I decided to split it into
> Sergio> a separate patch. This is going to be needed by the ptrace-error
> Sergio> feature; GDB will need to be able to access the value of errno even
> Sergio> after a call to our 'perror'-like functions.
>
> I'm in favor of this. The existing code seems pretty ugly.

I'm not sure in favor of relying on errno being preserved from
throw site to catch site, with potentially multiple try/catch hops
in between. Sergio, can you point out exactly how you're
intending to use that?

But, I'm in favor of removing this errno/bfd_error clearing too.

We used to have more global state clearing around this area,
but it's been gradually removed. E.g.:

commit 0af679c6e0645a93d5a60ec936b94dc70a2f9e5c
Author: Pedro Alves <palves@redhat.com>
AuthorDate: Tue Apr 12 16:49:30 2016 +0100
Commit: Pedro Alves <palves@redhat.com>
CommitDate: Tue Apr 12 16:55:35 2016 +0100

Don't call clear_quit_flag in prepare_to_throw_exception

I think this is reminiscent of the time when a longjmp would always
jump to the top level. Nowaways code that throw exceptions other than
a quit, which may even be caught and handled without reaching the top
level. Certainly such exceptions shouldn't clear an interrupt
request...

I suspect this perror_with_name errno/bfd_error clearing was also
related to ancient direct longjmp to the top level.

> I'd imagine it's unlikely that any caller would rely on this.
> If it tested cleanly then that is good enough for me.

>
> Sergio> Another small hunk is the one that saves/restores errno on gdbserver's
> Sergio> 'perror_with_name', but this one is pretty trivial, I think.
>
> I didn't understand why this one was needed.
> Does safe_strerror reset errno? Maybe a comment would be in order.
Thanks,
Pedro Alves