fix remote serial read

fix remote serial read

[Сергей Чернов]

[-- Attachment #1: Type: text/plain, Size: 2164 bytes --]


After closing "Bug 30770 - serial.c does not preserve errno correctly"
https://sourceware.org/bugzilla/show_bug.cgi?id=30770
remote debugging became impossible due to an attempt to recv() by a call intended for the socket, and not for the character device file. The documentation implicitly states that it is possible to use the read() call to work with a socket. But this does not mean in the general case that it is permissible to use recv in the case of a non-socket.
 
condition:
os: Distributor ID:    Ubuntu
Description:    Ubuntu 23.10
Release:    23.10
Codename:    mantic
 
libc:  
ldd (Ubuntu GLIBC 2.38-1ubuntu6) 2.38
kernel:
Linux klen-dev-um790pro 6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:59:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
gdb: build from trank at 15.0.50.20231226-git
 
GDB output:
$ arm-kgp-eabi-gdb
GNU gdb (Klen's_GNU_package_(KGP)_for_target::arm-kgp-eabi<rmprofile/lto>_host::x86_64-kgp-linux-gnu_znver4-avx512<<ílex>>) 15.0.50.20231226-git
....
(gdb) tar ext /dev/ttyACM1
Remote debugging using /dev/ttyACM1
Remote communication error.  Target disconnected: error while reading: Socket operation on non-socket.
(gdb)
 
after fix gdb work fine
 
$ arm-kgp-eabi-gdb -q
(gdb) tar ext /dev/ttyACM0
Remote debugging using /dev/ttyACM0
(gdb) mon swd
Target voltage: 0.0V
Available Targets:
No. Att Driver
       STM32F40x M4
(gdb) att 1
Attaching to Remote target
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x08020c80 in ?? ()
(gdb)
 
 
---
 gdb/ser-unix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
diff --git a/gdb/ser-unix.c b/gdb/ser-unix.c
index 07cd8b7b5b4..57dcf6c7cf3 100644
--- a/gdb/ser-unix.c
+++ b/gdb/ser-unix.c
@@ -574,7 +574,7 @@ when debugging using remote targets."),
 int
 ser_unix_read_prim (struct serial *scb, size_t count)
 {
-  int result = recv (scb->fd, scb->buf, count, 0);
+  int result = read (scb->fd, scb->buf, count);
   if (result == -1 && errno != EINTR)
     perror_with_name ("error while reading");
   return result;
--
2.40.1

Re: fix remote serial read

[Tom Tromey]

>>>>> Сергей Чернов <klen_s@mail.ru> writes:

> After closing "Bug 30770 - serial.c does not preserve errno correctly"
> https://sourceware.org/bugzilla/show_bug.cgi?id=30770
> remote debugging became impossible due to an attempt to recv() by a call intended for the socket, and not for the character device file. The
> documentation implicitly states that it is possible to use the read() call to work with a socket. But this does not mean in the general case that it is
> permissible to use recv in the case of a non-socket.
 
This patch wasn't sent in a way that was easy to apply, but I've gone
ahead and done it manually.  I'm going to push it shortly.

Tom

Re: fix remote serial read

[Сергей Чернов]

[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]


Hello Tom!
 
my git client did not allow me to make a email-like patch automatically (for some reason it works with an error) and I, knowing the format, wrote it by hand... apparently I work no better than him :)
Thank you for making the correction to trunk gdb sources, I will be pleased if my name is mentioned :)
Every day I develop tools for developing and debugging embedded devices based on cortex-m and little riscv - so I detect errors with GCC and GDB local and remote hardware debugging immediately. At the same time, I have accumulated patches that could be offered to the public. Perhaps it would be nice if we collaborated for the common good.
There are ideas on how to improve riscv debugging in the direction of indicating only the actually implemented special registers (SCR) of the processor. I plan to try this and will share the result for discussion. I'm involved in improving the GCC target-port ror RISCV and apparently this could be matched by an improvement in bu/gdb.
 
Best regards
Chernov Sergey aka Klen Santakheza
>Пятница, 19 января 2024, 21:02 +03:00 от Tom Tromey <tom@tromey.com>:
> 
>>>>>> Сергей Чернов < klen_s@mail.ru > writes:
> 
>> After closing "Bug 30770 - serial.c does not preserve errno correctly"
>>  https://sourceware.org/bugzilla/show_bug.cgi?id=30770
>> remote debugging became impossible due to an attempt to recv() by a call intended for the socket, and not for the character device file. The
>> documentation implicitly states that it is possible to use the read() call to work with a socket. But this does not mean in the general case that it is
>> permissible to use recv in the case of a non-socket.  
>This patch wasn't sent in a way that was easy to apply, but I've gone
>ahead and done it manually. I'm going to push it shortly.
>
>Tom
 

Re: fix remote serial read

[Simon Marchi]

On 2024-01-20 06:56, Сергей Чернов wrote:
> Hello Tom!
>  
> my git client did not allow me to make a email-like patch
> automatically (for some reason it works with an error) and I, knowing
> the format, wrote it by hand... apparently I work no better than him
> :)

Would it be possible to know what the problem was?

The ideal way to send a patch is git-send-email, which sends the patch
through an SMTP server directly as a properly formatted email.  But I
understand that it's not always trivial to set up.

The second best way would be to use git-format-patch to generate a
.patch file, and then send that file as an attachment (not copy pasting
it in your email client).  This doesn't really need any setup, so I
don't see any reason why that wouldn't be possible.

Simon

Re: fix remote serial read

[Tom Tromey]

>>>>> Сергей Чернов <klen_s@mail.ru> writes:

> Every day I develop tools for developing and debugging embedded
> devices based on cortex-m and little riscv - so I detect errors with
> GCC and GDB local and remote hardware debugging immediately. At the
> same time, I have accumulated patches that could be offered to the
> public. Perhaps it would be nice if we collaborated for the common
> good.

Sounds good to me, we're always interested in improvements.

You should probably start on the copyright assignment process.  This is
needed when someone sends more than just a trivial patch.  You can email
'assign@gnu.org' to get started on this.

Tom