This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix logic in exec_file_locate_attach


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]