[lldb-dev] problems using EvaluateExpression in lldb, when it creates new object

[fhjiwerfghr fhiewrgfheir via lldb-dev]

I'm sorry in advance, if it's not a correct mailing list, there doesn't
seem to be lldb-usage mailing list.

I'm writing a pretty-printer python script, which - to cut to the chase,
pretty prints members of a class by using EvaluateExpression and creating
new object inside it. It doesn't seem to work - i'm getting "" error. Should my idea work in a first place and i't s a bug
or it shouldn't and i need to find a different solution?

I'm attaching a repro case:

clang++ q.cpp -g -o o -std=c++20
lldb o
command script import lldb_script.py
br set --file q.cpp --line 19
r
print c


it prints:
(lldb) print c
(C) $0 = CCC {
   = 
}

it should something akin to:
(lldb) print c
(C) $0 = CCC {
  b   = B {
a = A {
  id = "qwerty"
}
  }
}
#include 
#include 
#include 

struct A {
std::string_view id() const { return "qwerty"; }
};

struct B {
A a() const { return A(); }
};
struct C {
B b() const { return B(); }
};

int main()
{
C c;
return 0;
}
import lldb.formatters.Logger
import lldb
import logging
import sys
import codecs
import platform
import json

logger = lldb.formatters.Logger.Logger()

logfile = codecs.open('log.txt', 'wb', encoding='utf8')
log = logging.getLogger()
log.setLevel(logging.INFO)
FORMAT = "[%(filename)s:%(lineno)s] %(message)s"
if log.handlers:
log.handlers[0].setFormatter(logging.Formatter(FORMAT))

ch = logging.StreamHandler(logfile)
ch.setLevel(logging.DEBUG)
formatter = logging.Formatter(FORMAT)
ch.setFormatter(formatter)
log.addHandler(ch)

log.error('---')
log.error('starting')

module = sys.modules[__name__]

if sys.version_info[0] == 2:
# python2-based LLDB accepts utf8-encoded ascii strings only.
def to_lldb_str(s): return s.encode(
'utf8', 'backslashreplace') if isinstance(s, unicode) else s
range = xrange
else:
to_lldb_str = str

log = logging.getLogger(__name__)

class V(object):
def __init__(self, v, dict=None):
self.v = v

def EvaluateExpression(self, expr, name=None):
v = self.v.CreateValueFromExpression(name, expr).dynamic
assert v
return V(v)


class Base(V):
regex = False

def get_summary(self):
return ''

def update(self):
pass

def num_children(self):
return 0

def has_children(self):
return False

def get_child_at_index(self, index):
return None

def get_child_index(self, name):
return -1


class cc_A(Base):
type = 'A'
regex = False

def num_children(self):
return 1

def has_children(self):
return True

def get_child_at_index(self, index):
assert index == 0
v = self.EvaluateExpression(f"id()", f'id')
return v.v

class cc_B(Base):
type = 'B'
regex = False

def num_children(self):
return 1

def has_children(self):
return True

def get_child_at_index(self, index):
assert index == 0
v = self.EvaluateExpression(f"a()", f'a')
return v.v

class cc_C(Base):
type = 'C'
regex = False

def get_summary(self):
return 'CCC'

def num_children(self):
return 1

def has_children(self):
return True

def get_child_at_index(self, index):
assert index == 0
return self.EvaluateExpression(f"b()").v

def initialize_category(debugger):
global module, std_category

std_category = debugger.CreateCategory('C++')
std_category.SetEnabled(True)

glob = globals()
todo = []
log.error('initialize_category')
def add(a, b, c, d):
todo.append(lambda: a(b, c, d))
for x, c in glob.items():
if x.startswith('ff_'):
if isinstance(c.type, list):
for t in c.type:
add(attach_summary_to_type, c, t, c.regex)
else:
add(attach_summary_to_type, c, c.type, c.regex)
elif x.startswith('cc_'):
if isinstance(c.type, list):
for t in c.type:
add(attach_synthetic_to_type, c, t, c.regex)
else:
add(attach_synthetic_to_type, c, c.type, c.regex)
for d in todo:
d()

def attach_synthetic_to_type(synth_class, type_name, is_regex=False):
global module, std_category

#log.info('attaching synthetic %s to "%s", is_regex=%s', synth_class.__name__, type_name, is_regex)
synth = lldb.SBTypeSynthetic.CreateWithClassName(
__name__ + '.' + synth_class.__name__)
synth.SetOptions(lldb.eTypeOptionCascade)
std_category.AddTypeSynthetic(
lldb.SBTypeNameSpecifier(type_name, is_regex), synth)

def summary_fn(valobj, dict): return get_synth_summary(synth_class, valobj, dict)
# LLDB accesses summary fn's by name, so we need to create a unique 

[lldb-dev] LLDB Windows on Arm64 buildbot

[Omair Javaid via lldb-dev]

Hi,

This is to notify that we are in process of setting up a LLDB Windows on
Arm64 buildbot which will help share the load of maintenance of LLDB
Windows platform support.

Should you have any query or suggestions please feel free to contact us.

Thanks!

--
Omair Javaid
www.linaro.org
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [EXTERNAL] LLDB Windows on Arm64 buildbot

[Stella Stamenova via lldb-dev]

That's very exciting!

Please let me know if you run into any issues I could help with.

Thanks,
-Stella

From: Omair Javaid 
Sent: Friday, January 14, 2022 2:12 PM
To: mailing list lldb-dev 
Cc: Stella Stamenova 
Subject: [EXTERNAL] LLDB Windows on Arm64 buildbot

You don't often get email from 
omair.jav...@linaro.org. Learn why this is 
important
Hi,

This is to notify that we are in process of setting up a LLDB Windows on Arm64 
buildbot which will help share the load of maintenance of LLDB Windows platform 
support.

Should you have any query or suggestions please feel free to contact us.

Thanks!

--
Omair Javaid
www.linaro.org
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Source-level stepping with emulated instructions

[Kjell Winblad via lldb-dev]

Hi!

I'm implementing LLDB support for a new processor architecture that
the company I'm working for has created. The processor architecture
has a few emulated instructions. An emulated instruction works by
jumping to a specific address that contains the start of a block of
instructions that emulates the emulated instructions. The emulated
instructions execute with interrupts turned off to be treated as
atomic by the programmer. So an emulated instruction is similar to a
function call. However, the address that the instruction jumps to is
implicit and not specified by the programmer.

I'm facing a problem with the emulated instructions when implementing
source-level stepping (the LLDB next and step commands) for C code in
LLDB. LLDB uses hardware stepping to step through the address range
that makes up a source-level statement. This algorithm works fine
until the PC jumps to the start of the block that implements an
emulated instruction. Then LLDB stops because the PC exited the
address range for the source-level statement. This behavior is not
what we want. Instead, LLDB should ideally step through the emulation
instructions and continue until the current source-level statement has
been completed.

My questions are:

1. Is there currently any LLDB plugin functionality or special DWARF
debug information to handle the kind of emulated instructions that I
have described? All the code for the emulated instructions is within
the same address range that does not contain any other code.
2. If the answer to question 1 is no, do you have suggestions for
extending LLVM to support this kind of emulated instructions?

Best regards,
Kjell Winblad
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

[Tom Stellard via lldb-dev]

On 12/17/21 13:15, Tom Stellard wrote:

Hi,

Here is a proposal for a new automated workflow for managing parts of the 
release
process.  I've been experimenting with this over the past few releases and
now that we have migrated to GitHub issues, it would be possible for us to
implement this in the main repo.

The workflow is pretty straight forward, but it does use pull requests.  My
idea is to enable pull requests for only this automated workflow and not
for general development (i.e. We would still use Phabricator for code review).
Let me know what you think about this:



Hi,

Thanks for the feedback on this.  I've posted a patch to implement this 
proposal:
https://reviews.llvm.org/D117386.  The only change is that the pull requests 
will
not be in the llvm/llvm-project repo, but will instead be in 
llvmbot/llvm-project.
This will reduce the number of notifications and avoid confusion about whether 
or
not we are using pull requests for this project.

-Tom



# Workflow

* On an existing issue or a newly created issue, a user who wants to backport
one or more commits to the release branch adds a comment:

/cherry-pick  <..>

* This starts a GitHub Action job that attempts to cherry-pick the commit(s)
to the current release branch.

* If the commit(s) can be cherry-picked cleanly, then the GitHub Action:
     * Pushes the result of the cherry-pick to a branch in the
   llvmbot/llvm-project repo called issue, where n is the number of the
   GitHub Issue that launched the Action.

     * Adds this comment on the issue: /branch llvmbot/llvm-project/issue

     * Creates a pull request from llvmbot/llvm-project/issue to
   llvm/llvm-project/release/XX.x

     * Adds a comment on the issue: /pull-request #
   where n is the number of the pull request.

* If the commit(s) can't be cherry-picked cleanly, then the GitHub Action job 
adds
the release:cherry-pick-failed label to the issue and adds a comment:
"Failed to cherry-pick  <..>" along with a link to the failing
Action.

* If a user has manually cherry-picked the fixes, resolved the conflicts, and
pushed the result to a branch on github, they can automatically create a pull
request by adding this comment to an issue: /branch //

* Once a pull request has been created, this launches more GitHub Actions
to run pre-commit tests.

* Once the tests complete successfully and the changes have been approved
by the release manager, the pull request can me merged into the release branch.

* After the pull request is merged, a GitHub Action automatically closes the
associated issue.

Some Examples:

Cherry-pick success: https://github.com/tstellar/llvm-project/issues/729
Cherry-pick failure: https://github.com/tstellar/llvm-project/issues/730
Manual Branch comment: https://github.com/tstellar/llvm-project/issues/710


# Motivation

Why do this?  The goal is to make the release process more efficient and 
transparent.
With this new workflow, users can get automatic and immediate feedback when a 
commit
they want backported doesn't apply cleanly or introduces some test failures.  
With
the current process, these kinds of issues are communicated by the release 
manager,
and it can be days or even weeks before a problem is discovered and 
communicated back
to the users.

Another advantage of this workflow is it introduces pre-commit CI to the 
release branch,
which is important for the stability of the branch and the releases, but also 
gives
the project an opportunity to experiment with new CI workflows in a way that
does not disrupt development on the main branch.

# Implementation

If this proposal is accepted, I would plan to implement this for the LLVM 14 
release cycle based
on the following proof of concept that I have been testing for the last few 
releases:

https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml
https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml
https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml

Thanks,
Tom


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev