Re: [PATCH v2] Fix logic in exec_file_locate_attach

Gary Benson
2016-02-23T11:27:28Z

Luis Machado wrote:
> On 02/22/2016 09:13 PM, Pedro Alves wrote:
> > On 02/23/2016 12:04 AM, Luis Machado wrote:
> > >On 02/22/2016 08:00 PM, Pedro Alves wrote:
> > > > On 02/22/2016 10:49 PM, Luis Machado wrote:
> > > > > On 02/22/2016 07:00 PM, Luis Machado wrote:
> > > > > > My idea was to guard both exec_file_attach and
> > > > > > symbol_file_add_main. We can't have anything in that
> > > > > > function throwing an error that won't be caught, otherwise
> > > > > > the above connection attempt will fail.
> > > > >
> > > > > For the record, you patch does fix the case of native GDB
> > > > > trying to attach to a process without pre-loading a symbol
> > > > > file. We get a multi-frame backtrace as expected.
> > > > >
> > > > > It is the gdb/gdbserver case that still seems to be broken.
> > > >
> > > > Native is also broken as well for unexpectedly aborting the
> > > > attach sequence midway. While "bt" doesn't show it, "detach"
> > > > does trip on it:
> > >
> > > Sounds like we're looking into a try/catch block around such
> > > functions then?
> >
> > Yes, I think so. Probably best to make it two separate
> > try/catches, in case the file can't be loaded as executable but
> > succeeds as symbol file, for some reason.
>
> Ok. I have the code in place, but i'm still crafting the testcase
> for both native / remote cases. Should have something later this
> week.

I hadn't considered user interrupts.

Pedro, are you ok if I commit my v2 patch
(https://sourceware.org/ml/gdb-patches/2016-02/msg00587.html)
as a fix for the sysroot-escaping behaviour we saw?

Thanks,
Gary

--