This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2] Fix logic in exec_file_locate_attach
- From: Pedro Alves <palves at redhat dot com>
- To: Luis Machado <lgustavo at codesourcery dot com>, Gary Benson <gbenson at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 23 Feb 2016 00:13:55 +0000
- Subject: Re: [PATCH v2] Fix logic in exec_file_locate_attach
- Authentication-results: sourceware.org; auth=none
- References: <20160219102447 dot GA29870 at blade dot nx> <1455880879-310-1-git-send-email-gbenson at redhat dot com> <56C736ED dot 9040505 at codesourcery dot com> <20160222104034 dot GA31531 at blade dot nx> <56CAF2E3 dot 7050607 at codesourcery dot com> <20160222135109 dot GA2256 at blade dot nx> <56CB8506 dot 3010602 at codesourcery dot com> <56CB9095 dot 9090908 at codesourcery dot com> <56CB9304 dot 9020408 at redhat dot com> <56CBA220 dot 3000709 at codesourcery dot com>
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.
Thanks,
Pedro Alves