I think LLVM produces some cases like this (maybe not at sequence end,
but for other instructions (emit two copies without an advance PC
between them (but maybe an advance line, etc) - in both cases, yeah,
I'd consider this to be probably-valid-but-trivially-inefficient
output. The way I think of
my 2c: "If STRP forms are allowed only in DWO files which cannot be
combined into a DWP file, then a packaging utility should be smart enough
to detect such input files and reject them. As there is no simple sign for
that, the tool should analyze sections in input files to check if those
forms are
On Fri, Apr 10, 2020 at 4:20 PM Jay Kamat wrote:
> Ah, I see, that makes a lot of sense. However, I have a couple questions:
>
> > The DW_AT_type of v1 and the DW_AT_type of t2::m1 would need to
> point
> > to the same DIE, otherwise there would be much confusion about these
> being
> >
Not aware of that specific tool - though debugger load time can be greatly
improved by the use of some kind of debugger index. If their debugger of
choice is GDB, then -ggnu-pubnames + -Wl,-gdb-index (with gold or lld) has
made things pretty usable for my needs in LLVM development, and seems to
"quality of implementation" thing - but in general, even if a few bugs were
fixed/improvements were made to both Clang and GCC, it's going to be
hard/impossible to track certain things through templates in DWARF - for
similar reasons that it's hard to provide diagnostic messages that describe
On Sun, Mar 29, 2020 at 3:44 PM Cary Coutant wrote:
> >> > Yep - unless someone has significant objections my plan is currently:
> >> >
> >> > Emit a v5 index with extension/non-standard extra column indexes
> (specifically: DW_SECT_LOC and 9 and DW_SECT_MACINFO at 10). I hope those
> can at
On Sun, Mar 29, 2020 at 2:56 PM Cary Coutant wrote:
> > Not to derail this thread, but another thing that might be worth
> checking is: should debug_aranges include non-code addresses. GCC's don't,
> Clang's do. Sounds like Clang's correct, but GCC is sort of the defacto
> standard DWARF
Not to derail this thread, but another thing that might be worth checking
is: should debug_aranges include non-code addresses. GCC's don't, Clang's
do. Sounds like Clang's correct, but GCC is sort of the defacto standard
DWARF producer, so might be worth getting an authoritative
On Tue, Mar 10, 2020 at 1:31 AM Pavel Labath wrote:
> On Mon, 9 Mar 2020 at 23:13, David Blaikie wrote:
> >
> >
> >
> > On Wed, Feb 26, 2020 at 1:05 AM Pavel Labath wrote:
> >> Yes, the lack of an official extension space is unfortunate, but I
> >> don't think this needs to be a blocker -- the
On Wed, Feb 26, 2020 at 1:05 AM Pavel Labath wrote:
> On Tue, 25 Feb 2020 at 21:36, David Blaikie wrote:
> >
> >
> >
> > On Tue, Feb 25, 2020 at 11:41 AM Pavel Labath wrote:
> >>
> >> Yeah, this sounds tricky, but it is actually good timing, because I
> >> was just about to start working on
On Wed, Feb 26, 2020 at 6:29 AM Michael Eager wrote:
> On 2/26/20 1:05 AM, Pavel Labath via Dwarf-Discuss wrote:
> > The main question on my mind now is, what is the likely future
> > direction of the DWARF spec -- if say DWARF v6 adds a new section, how
> > will it handle mixed v5+v6
On Tue, Feb 25, 2020 at 11:41 AM Pavel Labath wrote:
> Yeah, this sounds tricky, but it is actually good timing, because I
> was just about to start working on DWP v5 in lldb. I was hoping that
> would be an easy ride, but it looks like things will get complicated.
>
> On Tue, 25 Feb 2020 at
(please add anyone who has a vested interest in Split DWARF in general and
dwp in particular)
tl;dr:
How should DWARFv4 and DWARFv5 coexist in a DWP file:
1) Not at all (invalid/unsupported)
2) Single index table where the section indexes are subjective (look at the
version of the referenced
On Wed, Jul 24, 2019 at 11:06 AM David Anderson via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> I've noticed that the documentation of split dwarf and the various CU
> header
> unit codes has a possible deficiency.
>
> For example, in sections F.2 and F.3 (examples, not the
FWIW - if we're talking about assembly extensions, another one LLVM could
use (it currently is one of the few things where Clang's integrated
assembler can emit object code that can't be represented via textual
assembly output) is the ability to express multiple line tables in a single
assembly
Yep - sounds like it to me.
I suppose, arguably, one could say that successful name lookups of things
in the index can be fast, while lookups that fail, or find names not in the
index may be slow - but that seems unacceptable to me (in many cases "slow"
would be "prohibitively slow" especially
101 - 116 of 116 matches
Mail list logo
