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
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
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
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
> 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
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_
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
> 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
> 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
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 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
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
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
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
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
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
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,
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'
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
19 matches
Mail list logo
