public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Luis Machado <lgustavo@codesourcery.com>
To: Gary Benson <gbenson@redhat.com>, Pedro Alves <palves@redhat.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Fix logic in exec_file_locate_attach
Date: Fri, 19 Feb 2016 10:33:00 -0000	[thread overview]
Message-ID: <56C6EF5A.8080906@codesourcery.com> (raw)
In-Reply-To: <20160219102447.GA29870@blade.nx>

On 02/19/2016 08:24 AM, Gary Benson wrote:
> Pedro Alves wrote:
>> On 02/18/2016 05:05 PM, Gary Benson wrote:
>>> 	* exec.c (exec_file_locate_attach): Throw error if
>>> 	exec_file_find fails to locate the main executable.
>>
>> This goes back to:
>>    https://sourceware.org/ml/gdb-patches/2016-02/msg00413.html
>>
>> Why is this an error, that even makes us stop the attach process
>> halfway, if the case when we don't know the file name is completely
>> silent? :
>
> Hmmm, I was trying to fix a test failure, but looking at it with fresh
> eyes this morning it would've been better to fix up that test as the
> resulting state is more usable without a throw.  This is with throw:
>
>    (gdb) set sysroot /whatever
>    (gdb) attach 31954
>    Attaching to process 31954
>    ../attach-bad-sysroot: in sysroot "/whatever": No such file or directory.
>    (gdb) bt
>    #0  0xb54aca20 in ?? ()
>    Backtrace stopped: Cannot access memory at address 0x25ae1df8
>    (gdb)
>
> This is without throw:
>
>    (gdb) set sysroot /whatever
>    (gdb) attach 31954
>    Attaching to process 31954
>    warning: Could not load vsyscall page because no executable was specified
>    try using the "file" command first.
>    0x00000039b54aca20 in ?? ()
>    (gdb) bt
>    #0  0x00000039b54aca20 in ?? ()
>    #1  0x00000039b54ac8b0 in ?? ()
>    #2  0x0000000000000000 in ?? ()
>    (gdb)
>
> So without the throw you can backtrace.  Also, not throwing will I
> think fix things for Luis without adding TRY..CATCH in remote.c.
> I'll rework and resubmit.

For the record, i'm re-working my previous patch to handle the case of 
native attaches too, when the file access problem cuts the attachment 
process halfway through (regardless of sysroot use policies).

I'm playing around with the TRY/CATCH block inside 
exec_file_locate_attach as opposed to taking care of its callers (in 
remote.c and infcmd.c).

Currently i'm checking for regressions and writing a testcase. I just 
want to make sure our changes don't overlap in terms of logic.

  reply	other threads:[~2016-02-19 10:33 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-11 14:19 [PATCH] Remote debugging without a binary (regression) 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 [this message]
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
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=56C6EF5A.8080906@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).