This is the mail archive of the 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: PING: Re: [RFC 00/12] Merge value optimized_out and unavailable

On 29/08/2013 6:20 PM, Andrew Burgess wrote:
> Ping!

Ping #2!

It's been a while, but I still have interest in merging this work.

I've not checked to see if the patches still apply, if there's anyone
who's willing to review this work then let me know and I'll refresh the
patch series.

I know I'm still a fairly new / small time contributor to gdb, and this
patch set is a refactor, not a bug fix, so I might be getting ahead of
myself trying to have something like this merged :)  That's OK, if you
let me know then I'll not spend any more time on this work.


> On 12/08/2013 1:15 PM, Andrew Burgess wrote:
>> This patch set merges together how gdb handles values that are
>> optimized out and values that are unavailable.
>> I think that in most cases gdb should not care why the contents of
>> a value are not fetch-able, it is only when we need to display
>> something to the user that we should have to figure out was this
>> optimized-out or unavailable?
>> After this patch set there will be a single unified interface to ask
>> if a value is available (either fully, partially, or for a range of
>> bit/bytes), this will answer in terms of both optimized out and
>> unavailable state.
>> A second method will fetch the set of flags for the value
>> optimized/unavailable, this will be used for printing the correct string.
>> For the implementation I've moved away from the code we currently have
>> for supporting partially optimized out values and consolidated on the
>> unavailable vector.
>> Currently within gdb there are places where we handle optimized out and
>> unavailable differently, resulting in different style of output, and there
>> are places where we handle one of optimized out or unavailable, but not the
>> other.  After this patch set it should (I hope) be much harder for either
>> of these situations to arise.
>> Looking forward to your feedback.
>> Thanks,
>> Andrew

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