eally the larger, full-unit-sized variant
would be the one using explicit sizes or a separate type variant
inheriting the same bounds.
But the problem I see, and try to raise in this thread, is that there's
no way for a subrange type to inherit bounds from another subrange type,
et size (in bits) for the type (which may require biased
representations, but that's besides the point). Despite the specified
size, standalone variables and members of unpacked types use full
storage units, unless packing is requested. See
e.g. https://gcc.gnu.org/git/?p=g
mmediate. Say, the base type could be a DW_TAG_const_type variant
>> of a subrange type. So, if we were to allow this sort of inheritance of
>> bounds, it should probably also cover multiple levels.
>> A simpler alternative could be to have another tag, say
>> DW_TAG_[un
This feels like a waste of a tag, though; DW_TAG_subrange_type seems
like it could be enough.
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Disinformation flourishes because many people c
statement-frontier-notes-and-location-views/
I'm going to speak about this at the upcoming GNU Tools Cauldron.
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin Am
ave these difficulties been run into before? Any advice to
share?
Thanks in advance,
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin Ameri
r of) the computer.
> but I'll add your proposals manually.
Thank you!
--
Alexandre Oliva, freedom fighterhttp://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|Re
and of a DW_FORM_sec_offset loclist. The offset identifies the
first entry of a loclist whose entries are to be regarded as part of
the loclist containing the list extension entry.
In Section 7.7.3, add to Table 7.10:
DW_LLE_extend_loclist | 0x0A
DW_LLE_extend_loclistx | 0x0B
--
Ale
On Mar 9, 2017, Alexandre Oliva wrote:
> a. a new kind of location list entry that specifies a pair of view
> numbers, that must be placed e.g. right before a bounded location
> description entry,
> b. several new kinds of location list entries, each corresponding to an
> e
ntroduce new loclist kind or kinds, in spite of breaking backward
compatibility of lists, or use a new attribute and list form to hold
view numbers?
Thanks in advance,
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gand
On Sep 9, 2016, Alexandre Oliva wrote:
> SFN stands for Statement Frontier Notes, a technique I specified several
> years ago and presented at the GCC Summit to allow for finer-grained
> location information, so as to enable debug information consumers to
> compute/observe multiple
On Sep 13, 2016, Alexandre Oliva wrote:
>> I'm thinking your view numbers might be similar to my logical
>> locations.
> I'm still digesting the information in the proposal and trying to
> confirm they're roughly equivalent, or can be easily made so
Consideri
re the former says "function_name" and suggests it
refers to a string, the latter says "subprogram" and refers to an entry
in the line number program header.
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- G
lt;4|1<<1|1)
Can anyone spot any problems with this proposal, particularly WRT the
fully implicit handling of view numbers in line number programs and
their use by compilers?
Is this (view numbers in line number tables, location list augmentation
with view numbers referenced by a new attrib
14 matches
Mail list logo
