Guilherme,
Could you please check if you have any structural differences between the
ASTs you see when
1) you first evaluate your expression at breakpoint A
2) you evaluate your expression the second time at breakpoint A ?
The AST of the expression evaluator's context is dumped once a TagDecl is
c
Thanks Jim, it helped a lot. But it bings other questions.
I managed to get the symbol by forcing the use of the DynamicLoaderStatic,
which is use only if the Strata is set to "eStrataRawImage".
What is "Strata" ?
Why is the Static DynamicLoader only use with the eStrataRawImage?
Right now, I don'
On Fri, Jul 12, 2019 at 10:35 AM Sam Elliott via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> Tom
>
> I attempted to use `git llvm push` with the test-suite repository (which
> isn’t moving to the monorepo) and it didn’t work. I presume this was
> expected
Sorry about that -- it should work now,
Hi Tom,
Thanks for driving this! It's a big project and it's great to see
the progress being made on it. My org's adaptation to the monorepo
is in progress as we speak.
I had two hopefully easy questions.
1) Can we get a link to the status page from the llvm.org front page?
That will make it
A "raw image" is one that loads all the code at some address and doesn't have a
dynamic loading mechanism. So it really just means "a binary that doesn't use
a dynamic loader." I'm not sure why it was called "Strata"...
But the Strata is used to disambiguate cases where the object file format
On 07/12/2019 10:29 AM, paul.robin...@sony.com wrote:
> Hi Tom,
>
> Thanks for driving this! It's a big project and it's great to see
> the progress being made on it. My org's adaptation to the monorepo
> is in progress as we speak.
>
> I had two hopefully easy questions.
> 1) Can we get a link
You might want to take a look at what the lldb-vscode process is doing by
attaching a debugger to it in case that will shed any light.
Other options are add a "initCommands" to your launch config:
"initCommands": ["log enable -f /tmp/log.txt lldb process"],
Then look at the log and see
You need to call SBDebugger::Initialize() before calling SBDebugger::Create().
Also, please use the SBLaunchInfo method for launching if possible where you
create a SBLaunchInfo, then call tgt.Launch() with the instance.
Other than that, as Jim said, you need to setup an event loop if you don't
On 11 Jul 2019, at 05:24, Tom Stellard via Release-testers
wrote:
>
> I've tagged the 8.0.1-rc4 release, please begin testing. This will
> (hopefully)
> be the last release candidate. If all goes well, I will tag the final release
> next Wednesday.
As with 8.0.1 rc3, I had to disable compile
We have a summary provider for std::string that is built into LLDB that must
not be working with the C++ runtime you are using. The current summary string
that is used is in source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp in
LoadLibStdcppFormatters:
lldb::TypeSummaryImplSP std_string_
> On Jun 21, 2019, at 1:24 PM, Joseph Tremoulet via lldb-dev
> wrote:
>
> Hi,
>
> I'm trying to use lldb in a project where I need to report stack traces from
> signal handlers, and need to do so on aarch64 Linux. Even for "synchronous"
> signal handling, I'm hitting a couple issues preve
> On Jun 18, 2019, at 7:08 AM, Romaric Jodin via lldb-dev
> wrote:
>
> Hello everyone,
>
> I am trying to add a new architecture into LLDB.
> My architecture is a accelerator with its own ISA for which we have a LLVM
> backend (release 7.1).
>
> I have started by creating a new NativeProces
Pavel stopped by a few days ago and we discussed this. SymbolVendor was
originally made to allow one or more object files to be used to provide the
most complete view of a program when debugging, but what happened is we put all
of the "using multiple files" kind of support down into the SymbolFi
Sounds like each register can very in size each time you stop if I read the
docs correctly. As Pavel said "dynamic_size_dwarf_expr" might work for you
here. Registers in a lldb_private::RegisterContext can have their sizes using:
uint32_t RegisterContext::UpdateDynamicRegisterSize(const
lldb_
> On Apr 3, 2019, at 10:05 AM, Alexander Polyakov via lldb-dev
> wrote:
>
> Hi lldb-dev,
>
> Currently I'm working on an OS plug-in for multiple operating systems and
> architectures, during my work, I noted a few moments I want to discuss with
> the community.
>
> 1) Adding RegisterContex
You might be able to set LLDB_DEBUGSERVER_LOG_FILE in the lldb program's
environment with a path, then set LLDB_SERVER_LOG_CHANNELS to a set of channels
that lldb-server will use when logging. It might give you some insight as to
what is going on. These environment variables will get passed alon
This is currently handled in each Platform subclass. The only platform that has
the ability to locate symbol automatically are the Darwin platforms and those
use DebugSymbols.framework to locate the symbols.
That being said, I have been thinking about doing this in a generic way that
would work
Fine to refactor any way that makes it easier for people to re-use or add new
VS Code DAP plug-ins! I agree with all comments so far.
Greg
> On Mar 13, 2019, at 12:50 AM, Pavel Labath via lldb-dev
> wrote:
>
> On 12/03/2019 20:34, Leonard Mosescu via lldb-dev wrote:
>> Greg, what do you think
I know several people here have been looking for a generic, cross-platform
way to locate symbols. One idea here was to make the symbol fetcher a
Python script that could use the SBAPI to interrogate the debugger to
determine what's needed. This isn't that different than a separate binary,
but it
19 matches
Mail list logo
