Hi!
On 2023-04-12 1:18 p.m., Jakub Jelinek wrote:
> On Wed, Apr 12, 2023 at 01:05:14PM +0100, Pedro Alves wrote:
>>> I thought Ben has posted the details.
>>> In memory they look the same as 0 based arrays, but they often have
>>> different calling conventions (argu
to array_type + vector
attribute,
and give the new attribute an optional value to identifies the vector flavor?
Pedro Alves
> On 64-bit ARM at least (unsure about RISCV), one can also have variable
> number element vectors, where the number of elements of the vector is
> determined by
On 2023-04-06 1:03 p.m., Jakub Jelinek via Dwarf-discuss wrote:
> On Thu, Apr 06, 2023 at 07:52:32AM -0400, Ron Brender wrote:
>>> And we almost certainly want to allow vectors on DWARF expression stack;
>>
>> What is so special about vector types in this regard. What do you have
>> against values
On 2023-04-06 12:03 p.m., Jakub Jelinek via Dwarf-discuss wrote:
>> define fixed-length vectors as special built-in types or is the goal to
>> support
>> arbitrary vector lengths?
>>
>> It might be good to maintain an upper limit on the size of a stack entry.
> I think it is better if consumers si
On 2023-04-04 11:09 a.m., Pedro Alves wrote:
> On 2023-04-04 12:22 a.m., Kyle Huey wrote:
>> On Mon, Apr 3, 2023 at 12:42 PM Pedro Alves via Dwarf-discuss
>> mailto:dwarf-discuss@lists.dwarfstd.org>>
>> wrote:
>>
>> Hi Ben,
>>
>> On
On 2023-04-04 12:22 a.m., Kyle Huey wrote:
> On Mon, Apr 3, 2023 at 12:42 PM Pedro Alves via Dwarf-discuss
> mailto:dwarf-discuss@lists.dwarfstd.org>>
> wrote:
>
> Hi Ben,
>
> On 2023-03-24 6:19 p.m., Ben Woodard via Dwarf-discuss wrote:
>
> &
_AT_threads_scaled and the one
> defining DW_AT_lower_bound and DW_AT_upper_bound.
>
> --------
> The subrange entry may have a DW_AT_variable_vector_width
> attribute, which is a flag. If present, this attriburte indicates
"attriburte" -> "attribute"
> that the width of a vector is defined by the hardware
> implementation of the target.
I think that saying:
that the width of a vector may be deduced based on knowledge of the ABI.
is more in line what is typically said in the spec.
Pedro Alves
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
On 2023-03-31 4:29 a.m., Ben Woodard wrote:
>> On Mar 30, 2023, at 1:27 PM, Pedro Alves wrote:
>>
>> On 2023-03-29 8:55 p.m., Ben Woodard via Dwarf-discuss wrote:
>>> *void f( float *a){}**
>>> *[30] pointer_type abbrev: 5
>>>
On 2023-03-30 9:26 p.m., Pedro Alves wrote:
> So teaching DWARF to specify the location of the return value is actually
> orthogonal
> here -- we need to be able to distinguish regular C array from vector arrays
> for
> other reasons too, specifically, the types are different
loat *" overload. Like:
typedef float __m128 __attribute__((vector_size(16)));
__m128 vec;
void func(float *a) { printf("ouch!\n"); }
int main()
{
// func(vec); // can't do this.
}
however, GDB does pick the float pointer overload:
(gdb) p func(vec)
ouch!
l that is lost otherwise, and the D.2.8 chapter in the
DWARF spec is
specifically about C/C++.
Or this is yet another case that people would prefer to leave things as is
DWARF-spec-wise
and we should go file bug reports with GCC and Clang?
Pedro Alves
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
On 2022-05-09 22:41, Robinson, Paul wrote:
>> Pedro Alves wrote:
>> On 2022-05-09 16:48, Ron Brender via Dwarf-Discuss wrote:
>>> So my suggestion is to file a bug report with CLANG, requesting they
>> correct their DWARF output to reflect all details needed
>>&
On 2022-05-06 21:08, Todd Allen via Dwarf-Discuss wrote:
> I'm agreeing with Michael that describing the unnamed bitfield seems dubious.
> If it does impact the ABI, I'm wondering if that impact is indirect: that is,
> the presence of this 0-width bit field changes an attribute of the next field,
>
well pedantically
claim that they _are_ following the spec. Shouldn't the spec be clarified here?
This then raises the question of whether a debugger can assume that the
presence of a DW_AT_bit_size
attribute indicates that the field is a bit field at the C/C++ source level.
GDB is assumin
sDebugging.html
is now returning "Not Found". Did the document move somewhere else?
Pedro Alves
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
e primary source file from
which the compilation unit was derived, or a DW_AT_source attribute whose
value is a null-terminated string containing the full contents of the source
code from which the compilation unit was derived.
Thanks,
Pedro Alves
___
Dwa
16 matches
Mail list logo
