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

[Sergio Durigan Junior <sergiodj@redhat.com>]

On Friday, February 28 2020, 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'd imagine it's unlikely that any caller would rely on this.
> If it tested cleanly then that is good enough for me.

As far as I have tested (buildbot and locally), everything is OK.

> 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.

Ah, no, safe_strerror doesn't reset errno.  As I explained in the commit
message, it is not allowed to do so.  The reason I decided to explicitly
save/restore errno is because I wanted to make sure that we (also
explicitly) follow the same rules for both GDB and gdbserver perror
functions.  But now I'm left thinking that I should have proposed the
same thing for 'throw_perror_with_name'...

Anyway, I'm fine with removing the save/restore from gdbserver's
perror.  I'll also remove the reference to it in the commit message.

Thanks,

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