> On Nov 7, 2021, at 12:36 PM, Todd Allen wrote:
>
> Just spitballing an idea here, but would there be value in a new DW_FORM (or
> two) that referenced the names from .strtab or .dynstr, instead of .debug_str?
> It would only work if the symbols already were there, but I would expect that
> f
On Sun, Nov 7, 2021 at 12:36 PM Todd Allen wrote:
>
> Just spitballing an idea here, but would there be value in a new DW_FORM (or
> two) that referenced the names from .strtab or .dynstr, instead of .debug_str?
Yeah, something along those lines have crossed my mind too - I haven't
looked into it
Just spitballing an idea here, but would there be value in a new DW_FORM (or
two) that referenced the names from .strtab or .dynstr, instead of .debug_str?
It would only work if the symbols already were there, but I would expect that
for many/most/all(?) functions defined in the compilation unit.
On Mon, Nov 1, 2021 at 7:14 PM Greg Clayton via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> LLDB also uses mangled names. The clang compiler is our expression parser
> and it always tries to resolve symbols during compilation/JIT and it
> supplies mangled names when looking for func
On Mon, Nov 1, 2021 at 10:14 PM Greg Clayton wrote:
> LLDB also uses mangled names. The clang compiler is our expression parser
> and it always tries to resolve symbols during compilation/JIT and it
> supplies mangled names when looking for functions to resolve when it JITs
> code up.
>
GDB was
LLDB also uses mangled names. The clang compiler is our expression parser and
it always tries to resolve symbols during compilation/JIT and it supplies
mangled names when looking for functions to resolve when it JITs code up. It is
nice to be able to do quick name lookups using these mangled nam
Finally, a question i know the answer to!
It brings us all the way back to when I was the C++ maintainer for GDB,
which is the most ancient of history.
Unfortunately, this a trip to a horrible place
I actually spent a lot of time trying to make it so we didn't need linkage
names, because, even the
>> > I wouldn't be averse to considering what'd take to make DWARF robust
>> > enough to always roundtrip simple and linkage names in this way - I don't
>> > think it'd take a /lot/ of extra DWARF content.
>>
>> Fuzzy memory here, but as I recall, GCC didn't generate linkage names
>> (or only did
On Mon, Nov 1, 2021 at 5:35 PM Cary Coutant wrote:
> >> I can't be sure about this exponential growth. I don't have the data
> to back it
> >> up. But I will say, when we created DWARF64, I was skeptical that it
> would be
> >> needed during my career. And yet here we are...
> >
> > Yep, still
>> I can't be sure about this exponential growth. I don't have the data to
>> back it
>> up. But I will say, when we created DWARF64, I was skeptical that it would
>> be
>> needed during my career. And yet here we are...
>
> Yep, still got mixed feelings about DWARF64 - partly the pieces that
On Mon, Nov 1, 2021 at 1:52 PM Todd Allen
wrote:
> Dave,
>
> If I understand right: The space saving you're expecting is the
> near-elimination
> of DW_AT_name strings. If they are only simple names like "T" and "int",
> they
> can be placed into the string table once each, and it should be very
Dave,
If I understand right: The space saving you're expecting is the near-elimination
of DW_AT_name strings. If they are only simple names like "T" and "int", they
can be placed into the string table once each, and it should be very small. But
you're expecting the DW_AT_linkage_name attributes
12 matches
Mail list logo
