Re: [PATCH] add more methods to gdb.Progspace

[Doug Evans <dje at google dot com>]

On Tue, Jun 17, 2014 at 8:14 PM, Doug Evans <dje@google.com> wrote:
> On Tue, Jun 17, 2014 at 6:33 PM, Tom Tromey <tromey@redhat.com> wrote:
>> There are a number of global functions in the gdb Python module which
>> really should be methods on Progspace.  This patch adds new methods to
>> Progspace and then redefines these globals in terms of these new
>> methods.  It also adds an Inferior.progspace attribute so that the
>> association between inferiors and progspaces is obvious; this lets us
>> apply the same treatment to current_progspace.
>>
> [...]
> Hi.  A few comments inline.
>
> solib_name(pc)
>
> This doesn't feel right as an element of the API.
> What if pc is in the main executable?  Can't the answer be found via
> other means?
> We've exported objfiles, so what does this bring to the table that,
> say, objfile_name (pc) doesn't?
> Or even better(?), symtab_and_line(pc) is all that's really needed, isn't it?
> [since one can, I think, get the objfile from the symtab; and if not
> we should provide that]

I guess a pc could be found that is in an objfile, and not in a
symtab, so symtab_and_line(pc) can be insufficient. But that still
leaves objfile_for_pc (pc), or some such.
If the user wants the name s/he can get it from the objfile.

> [Maybe there is a compelling reason to have it that I'm not seeing though.]

Still holds of course.