On Jan 26, 2018, Jakub Jelinek <[email protected]> wrote:
> Having to tweak debug info consumers so that they treat DW_LLE_* of 9
> one way for .debug_loclist of version 5 and another way for .debug_loclist
> of version 6 isn't a good idea.
Maybe we don't have to do that. The reason I implemented the proposed
format was to have a reference implementation, but since it's an
extension to a non-extensible part of DWARF5, it's hard to justify
consumer implementations for that.
> Why don't you emit the DW_LLE_GNU_view_pair stuff in .debug_loclists
> already with -gdwarf-5, if needed paired without some TU attribute that says
> that views are emitted?
Because that would make the loclists unreadable for any DWARF5-compliant
consumer.
> Haven't looked for it it in the coding standards, but it is something
> I've been asked to do in my code by various reviewers over the years and
> what I've been asking others in my patch reviews from others too.
Thanks. It was the first (well, second; you'd requested similar changes
another time before) I heard of that. I'm still unconvinced the way I
used is not compliant, but I'll keep that in mind. Hopefully I won't
run into someone who insists the other one (the one you reject) is the
only correct one ;-)
> I feel strongly about indenting stuff right,
I'm with you on that, we just have different ideas about what "right"
stands for ;-)
> which if it wouldn't fit would be
> return verylongcondition____________________________________
> && otherlongcondition__________________________________;
> rather than
> return verylongcondition____________________________________
> && otherlongcondition__________________________________;
> or similar, it would surprise me if it is not in the coding standard.
I agree neither of these two forms is correct.
But it is my understanding that both of the following are correct:
return (verylongcondition____________________________________
&& otherlongcondition__________________________________);
return verylongcondition____________________________________
&& otherlongcondition__________________________________;
The first, because the parenthesized expression is continued with
indentation to match the parenthesis, the second because the return
statement is continued with the correct indentation for the continuation
of a statement.
>> Personally, I don't see that line breaks before operators are only
>> permitted when the operand that follows wouldn't fit; the standards are
> Yes, you can break it, but why, it doesn't make the code more readable,
> but less in this case.
I thought it made it more readable, especially in the context of the
patch. I guess this means we'll have to agree to disagree.
> So, what is the reason not to emit the format you are proposing already with
> -gdwarf-5, perhaps with some extra attribute on the TU (of course not when
> -gstrict-dwarf)?
See above. We don't want to create unreadable loclists for
standard-compliant consumers, do we?
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
