public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Luis Machado <lgustavo@codesourcery.com>
To: Pedro Alves <palves@redhat.com>, <gdb-patches@sourceware.org>
Cc: <gbenson@redhat.com>
Subject: Re: [PATCH] Remote debugging without a binary (regression)
Date: Fri, 12 Feb 2016 17:31:00 -0000	[thread overview]
Message-ID: <56BE16CB.8050309@codesourcery.com> (raw)
In-Reply-To: <56BE0A1D.2070408@redhat.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
>

  reply	other threads:[~2016-02-12 17:31 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-11 14:19 Luis Machado
2016-02-11 16:35 ` Gary Benson
2016-02-11 17:06   ` Luis Machado
2016-02-11 17:31     ` Pedro Alves
2016-02-11 17:42       ` Luis Machado
2016-02-12 10:31     ` Gary Benson
2016-02-12 10:59       ` Luis Machado
2016-02-12 15:24       ` Pedro Alves
2016-02-17 13:53         ` Gary Benson
2016-02-17 14:40           ` Pedro Alves
2016-02-17 17:02           ` [OB PATCH] Add missing cleanup in exec_file_locate_attach Gary Benson
2016-02-17 17:05             ` Gary Benson
2016-02-17 18:11             ` Luis Machado
2016-02-18  9:54               ` Gary Benson
2016-02-18 17:05         ` [PATCH] Fix logic " Gary Benson
2016-02-18 17:28           ` Pedro Alves
2016-02-19 10:24             ` Gary Benson
2016-02-19 10:33               ` Luis Machado
2016-02-19 11:21               ` [PATCH v2] " Gary Benson
2016-02-19 15:38                 ` Luis Machado
2016-02-22 10:40                   ` Gary Benson
2016-02-22 11:37                     ` Luis Machado
2016-02-22 13:51                       ` Gary Benson
2016-02-22 22:00                         ` Luis Machado
2016-02-22 22:50                           ` Luis Machado
2016-02-22 23:00                             ` Pedro Alves
2016-02-23  0:04                               ` Luis Machado
2016-02-23  0:13                                 ` Pedro Alves
2016-02-23  0:16                                   ` Luis Machado
2016-02-23 11:27                                     ` Gary Benson
2016-02-23 11:43                                       ` Pedro Alves
2016-02-23 12:15                                         ` Gary Benson
2016-02-23 12:20                                           ` Pedro Alves
2016-02-23 11:55                 ` Pedro Alves
2016-02-24 11:56                   ` Gary Benson
2016-02-12 15:29 ` [PATCH] Remote debugging without a binary (regression) Pedro Alves
2016-02-12 16:08   ` Luis Machado
2016-02-12 16:36     ` Pedro Alves
2016-02-12 17:31       ` Luis Machado [this message]
2016-02-17 11:46         ` Pedro Alves
2016-02-18 12:30 ` Gary Benson
2016-02-18 12:40   ` Luis Machado

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56BE16CB.8050309@codesourcery.com \
    --to=lgustavo@codesourcery.com \
    --cc=gbenson@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).