This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Check if /proc is usable on gdbserver start
- From: Pedro Alves <palves at redhat dot com>
- To: Vyacheslav Barinov <v dot barinov at samsung dot com>, gdb-patches at sourceware dot org
- Date: Wed, 4 Jul 2018 10:57:13 +0100
- Subject: Re: [PATCH] Check if /proc is usable on gdbserver start
- References: <CGME20180704073447eucas1p1541c2021074eb8faa58e49f1abe8d733@eucas1p1.samsung.com> <20180704073447eucas1p1541c2021074eb8faa58e49f1abe8d733~_GikXtils0124801248eucas1p1n@eucas1p1.samsung.com>
On 07/04/2018 08:34 AM, Vyacheslav Barinov wrote:
> Hello,
>
> Just lost a couple of hours trying to find while gdb can't connect to gdbserver
> in my debug session.
>
> There's a buildroot where I want to debug a binary, and I tried to connect to
> it from outside, but got very weird errors like architecture mismatch or
> protocol errors. At last, after switching on '--debug' for gdbserver I found a
> message 'Can't open /proc/pid/' message and suddenly found that I forgot to
> mount procfs in my buildroot.
>
> I think it's better to check this before running gdbserver.
I'm not certain that it's a good idea to absolute require a /proc mount.
Even though we gradually moved into relying on /proc more (or better said, on
libthread_db less), over the years we've also tried to be tolerant to
missing /proc. I believe people had use cases for that (very constrained
containers or embedded systems? I don't recall exactly though...)
I assume that you're on either Aarch64 or x86_64 and that the architecture
mismatch is because gdbserver couldn't determine whether the process
was a 64-bit process, because that is done by reading the /proc/PID/exe
file. Maybe other 32-bit- or 64-bit-only archs still minimally work
without /proc.
I'm thinking that it may be prudent to downgrade this to a warning.
Would that work for you?
Thanks,
Pedro Alves