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: [RFC] Fix for gdb.parameter('architecture') returning empty string


>>>>> "Siva" == Siva Chandra <sivachandra@google.com> writes:

Tom> I suspect this means that gdb.parameter('architecture') will not always
Tom> show the same result as "show architecture".

Siva> I do not understand this completely. In my patch, show_architecture
Siva> only prints 'architecture_string'. Hence,
Siva> gdb.parameter('architecture') and "show architecture" should always
Siva> show the same result. Did I miss something?

Ok, I see.  Your patch removes the call to get_current_arch.
I missed that somehow before, sorry about that.

I think this just means that "show architecture" will now show incorrect
results, though.

Tom> But from what I can tell, the architecture-change observer is not
Tom> notified in every situation that might cause that function to return a
Tom> different result.

Siva> Pardon my ignorance here, does target arch change between frames?

I'm reasonably ignorant here myself.  I believe the answer is "yes",
albeit AFAIK just on SPU systems.

Tom> I think a better approach might be to address the problem of "auto" gdb
Tom> parameters more globally.  For example, we could add a method to the
Tom> appropriate CLI object so that the Python could call this to get the
Tom> correct current value.

Siva> Do you mean that the CLI object should have a method (which can
Siva> evaluate the property value on the go), rather than a property like
Siva> 'architecture_string' and 'endian_string'? If yes, do you envision
Siva> that Python make use of the method if it exists, otherwise use the
Siva> property?

Yes.  In this example, the method would resemble the current
show_architecture, but it would just return the name of the current
architecture, rather than all the surrounding text.

This method is only needed for "auto-capable" parameters.

One wrinkle in this plan is that the method in question would have to
return a union type, since parameters have different underlying
representations.


BTW, what is it you are using this for?  I think in many cases it is
preferable for us to expose more API directly rather than rely on CLI
settings.  E.g., if your code needs the architecture, find a way to
intelligently expose gdbarch on frames, types, etc.

Tom


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