Re: [PATCH 0/3] main_name cleanups

[Pedro Alves <palves at redhat dot com>]

On 01/06/2014 05:11 PM, Tom Tromey wrote:
> This series cleans up the "main_name" code both for multi-inferior and
> for the long-running objfile splitting project.
> 
> Currently, the name and language of main are globals.  Also, they can
> set in a couple of spots in the debuginfo readers.
> 
> Their global-ness can, I think, affect multi-inferior operation.  

Definitely.

> If
> you have two inferiors that have different main names, then I think
> perhaps some unwinding scenario could fail, because main_name will
> necessarily be incorrect for one of them, and because inside_main_func
> checks this value.  The fix here is to make the determination
> per-progspace.

Sounds right to me.

I was just wondering why duplicate the main name/language both in the
progspace and in the objfiles?  Wouldn't just storing a pointer to the
objfile that has the main name and its language in the progspace
be enough?  If not, then it'd be good to mention that in a comment,
I think.

> Setting them in the debuginfo readers is bad because, once debuginfo
> sharing happens, the second progspace to use the debuginfo will not
> pick up the main name automatically.  The fix here is to record the
> debuginfo readers' findings in the per-BFD object.
> 
> Let me know what you think.

-- 
Pedro Alves