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: [RFA 3/5] Use std::string, std::vector in rust-lang.c

On 09/23/2016 04:49 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <> writes:
> Pedro> There's a GNU extension that I think is meant to make it possible
> Pedro> for the debugger to treat uninitialized variables
> Pedro> specially (DW_OP_GNU_uninit), though I don't think we do
> Pedro> much with it.
> There were never any docs for it :(

I think all there is the original gcc and gdb patches:

I remember seeing these back then, but I was still a gdb noob then.
I don't recall the history of the feature after that.  From a quick look,
it kind of looks like some pieces of the patches are in the respective
trees, but not all hunks.  Maybe they got in, and then mostly reverted.

Pedro Alves

> I think it probably should have been a piece-terminating operation but
> it was never clear if this was how it was actually supposed to work.
> I stuck a comment in dwarf_expr_require_composition to this effect back
> in the day.
> Pedro> Not sure gcc emits it, even.
> It does, but I don't know under what conditions.
> There's code in dwarf2out.c like:
>   if (initialized == VAR_INIT_STATUS_UNINITIALIZED)
>     add_loc_descr (&result, new_loc_descr (DW_OP_GNU_uninit, 0, 0));
> I don't know when that happens though.
> Perhaps this could be cleaned up a bit, say by making DW_OP_GNU_uninit a
> piece terminator (I forget the official term here) and by changing gcc
> to emit a location list that indicates that the object is uninitialized
> until after the constructor is run.  It might be a little friendlier to
> users, dunno.
> Tom

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