This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Remote debugging without a binary (regression)
- From: Luis Machado <lgustavo at codesourcery dot com>
- To: Pedro Alves <palves at redhat dot com>, <gdb-patches at sourceware dot org>
- Cc: <gbenson at redhat dot com>
- Date: Fri, 12 Feb 2016 15:30:51 -0200
- Subject: Re: [PATCH] Remote debugging without a binary (regression)
- Authentication-results: sourceware.org; auth=none
- References: <1455200365-5270-1-git-send-email-lgustavo at codesourcery dot com> <56BDFA73 dot 9000001 at redhat dot com> <56BE038E dot 3060406 at codesourcery dot com> <56BE0A1D dot 2070408 at redhat dot com>
- Reply-to: Luis Machado <lgustavo at codesourcery dot com>
On 02/12/2016 02:36 PM, Pedro Alves wrote:
On 02/12/2016 04:08 PM, Luis Machado wrote:
I did not exercise that, but did not discard it either. I was attempting
to solve one problem at a time. There may be a failure there too.
I matters to determine where the TRY/CATCH should go, or even whether
the fix should be to not throw in the first place.
Ok, i crafted a test application that i can attach to via a remote
gdbserver and through the extended remote protocol.
I see the same error as before. On GDB's side, for example:
--
/lib64/ld-2.22.so: No such file or directory.
(gdb)
--
But it seems we have already attached to the process by the time we
error out. So we remain attached to it, just not sure if in a sane state:
--
(gdb) info proc
process 5464
warning: target file /proc/5464/cmdline contained unexpected null characters
cmdline = '/lib64/ld.so.1'
cwd = '/home/tester'
exe = '/lib64/ld-2.22.so'
(gdb) i r
zero at v0 v1 a0 a1 a2
a3
R0 000013aa 00000014 00000204 00000000 ffa831f8 ffa831f8 00000000
00000001
t0 t1 t2 t3 t4 t5 t6
t7
R8 ffa83060 557da7e0 00000000 015555f7 00000000 00000000 801123d8
00000000
s0 s1 s2 s3 s4 s5 s6
s7
R16 ffa83178 00020000 ffa830f8 00000000 00503bd8 00000000 004ee308
00000000
t8 t9 k0 k1 gp sp s8
ra
R24 00000038 55700e4c 00000000 00000000 557da7e0 ffa83000 ffa83240
55700ba0
status lo hi badvaddr cause pc
0400a4f3 00000000 00000017 557a20e4 00800020 55700e78
fcsr: 0x0
fir: 0x173890c
restart: 0x13aa
(gdb)
--
Like, with:
(gdb) define foo
attach PID
info threads
end
(gdb) foo
should failing to load the executable error out before
reaching "info threads", or continue.
I think it should not error out, like we don't error out
if the target doesn't support target_pid_to_exec_file
at all.
Agreed. In this case "info threads" doesn't run at all.
Thanks,
Pedro Alves