I'm adding LLDB support for an unconventional platform which uses two
stacks: one purely for return addresses and another for frame context
(spilled registers, local variables, etc). There is no explicit link
between the two stacks, i.e. the frame context doesn't include any
pointer or index to ide
to
> UnwindPlan::Row::RegisterLocation::RestoreType which handled this, I suppose.
>
>
> > On Mar 4, 2019, at 2:46 AM, Thomas Goodfellow via lldb-dev
> > wrote:
> >
> > I'm adding LLDB support for an unconventional platform which uses two
> > stacks: one p
suspect it may be a mild guideline for avoiding further pain on this
unconventional target: when necessary use the platform emulation to
fake its being conventional.
Cheers,
Tom
On Tue, 5 Mar 2019 at 12:55, Pavel Labath wrote:
>
> On 04/03/2019 11:46, Thomas Goodfellow via lldb-dev wrote:
&
I'm working with an embedded platform that segregates memory between
executable code, RAM, and constant values. The three kinds occupy
three separate address spaces, accessed by specific instructions (e.g.
"load from RAM address #0" vs "load from constant ROM address #0")
with fairly small ranges f
for upstreaming, since it lacks general availability, but
hopefully one of the exotic architectures lurking in the LLVM shadows
someday steps forth with a commitment to keep it alive in-tree.
Cheers,
Tom
On Mon, 3 Jun 2019 at 13:19, Pavel Labath wrote:
>
> On 03/06/2019 10:19, Thomas Goo
hance addr_t, or enhance Address, or create a new type for it. So,
> some sort of discussion that would clarify the concept a little bit is
> welcome, I think.
>
> Best regards.
>
> On 6/3/19 1:21 PM, Pavel Labath via lldb-dev wrote:
> > On 03/06/2019 10:19, Thomas Goodfe
I'm describing this initially through email rather than raising a defect
because I haven't developed a usable reproduction (I'm working on an
out-of-tree target based off the v8 release) and because it only bites with
DWARF logging enabled it's unlikely to affect many people.
The deadlock comes fr
We have a backend for a target that at present only detects some
assembler errors when emitting instructions (basically because the
platform has configurable properties with dependencies between
instructions and it was easier to check for their interaction late
than try to detect them earlier, e.g.
I saw the impending patch https://reviews.llvm.org/D62732, which suggests
that the current LLDB doesn't support RISC-V targets at all? If that's
correct, then do I understand correctly that the patch will support
bare-board debugging, e.g. via openocd?
Is there any sentiment on when the patch will
