We now have architecture plug-ins. Target::GetCallableLoadAddress should defer
to the architecture plug-ins and any functionality should be moved into those
plug-ins. There is one for ARM. We will need to make one for MIPS.
> On Jun 21, 2018, at 1:58 PM, Jim Ingham via lldb-dev
> wrote:
>
>
It's actually a little lame that we have a switch over architectures in generic
Target code. This should be gotten from the architecture plugin.
GetBreakableLoadAddress is even worse, there's ~150 lines of MIPS specific code
in Target.cpp, which seems really wrong to me.
Not really answering
Ah, I see. It looks like you have to set this before you create the process.
If I put this setting in my .lldbinit, or on the command line before I do "run"
it does limit the read size. But apparently once we've created the memory
cache we don't replace it when this value changes.
That's sti
A quick scan of the code looks like this should be hooked up, but you are
right, it doesn't seem to actually limit the cache page size. There's only one
test for this and that one just checks that the setting has some particular
value for android. Can you file a bug for this with bugs.llvm.org
Hi,
It seems Target::GetCallableLoadAddress does equivalent things for arm/thumb
and for mipses, just written in different forms. May I join these cases
together?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/l
Thanks! Disabling the cache worked.
Curiously, setting the line size seems to have no effect – it defaults to 512
(words, bytes, ...?), and still tries to read a page of guest memory regardless
of how small I set it.
Andrew
From: jing...@apple.com on beh
By default, lldb uses a memory cache to avoid making lots of tiny memory
requests, which tends to be inefficient especially when talking to a remote
device. You can turn this off with the "target.process.disable-memory-cache"
setting.
You can also adjust the cache page size with
"target.proce
Hi,
I’m trying to use lldb 6.0 on Linux to debug a process that has an SGX enclave
inside it. One of the data structures there (the “TCS”) only permits access to
certain fields. The problem is that when I try to access those fields in LLDB,
it tries to read an entire page of memory from the gue
https://bugs.llvm.org/show_bug.cgi?id=36871
Greg Clayton changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
I didn't know about llvm::SmallVector, but it seems a good match indeed,
thanks Greg.
On Thu, Jun 21, 2018 at 9:49 AM, Greg Clayton wrote:
>
>
> On Jun 21, 2018, at 9:46 AM, Leonard Mosescu wrote:
>
> Leonard, I'm not going to use your patch, as it's a bit un-llvm-y
>> (uses std::ostream and su
> On Jun 21, 2018, at 9:46 AM, Leonard Mosescu wrote:
>
> Leonard, I'm not going to use your patch, as it's a bit un-llvm-y
> (uses std::ostream and such). However, I wanted to check whether 20
> bytes will be enough for your use cases (uuids in minidumps)?
>
> For minidumps we normally use ei
>
> Leonard, I'm not going to use your patch, as it's a bit un-llvm-y
> (uses std::ostream and such). However, I wanted to check whether 20
> bytes will be enough for your use cases (uuids in minidumps)?
>
For minidumps we normally use either 16 or 20 byte UUIDs, so I don't see
any immediate probl
Indeed, thanks Greg. It dawned on my 1 min after I sent my post that I
failed to change my compile flags. Red-faced Duh. But thanks for the
additional info!
On Thu, Jun 21, 2018 at 11:34 AM, Greg Clayton wrote:
> I am guessing you don't have debug info enabled. Add "-g" to your command
> line wh
I am guessing you don't have debug info enabled. Add "-g" to your command line
when compiling. Or enable debug info in the Xcode settings.
On Mac, debug info is contained in the .o files. The main executable doesn't
have any debug info, but it has a debug map that tells LLDB how to link the
deb
That sounds like a plan. I have started cleaning up the class a bit
(removing manual uuid string formatting in various places and such),
and then I'll send a patch which implements that.
Leonard, I'm not going to use your patch, as it's a bit un-llvm-y
(uses std::ostream and such). However, I want
I cannot figure how to get a backtrace with filenames/line #s. Suggestions?
(And if this list is not the proper one to ask such questions, please
redirect me)
On OSX with:
$ lldb --version
lldb-900.0.64
Swift-4.0
For example:
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason =
I am fine if we go with any number of bytes. We should have the
lldb_private::UUID class have an array of bytes that is in the class that is to
to 20 bytes. We can increase it later if needed. I would rather not have a
dynamically allocated buffer.
That being said a few points:
- Length can be
https://bugs.llvm.org/show_bug.cgi?id=37893
Bug ID: 37893
Summary: Unable to resolve std::vector type in gmodules build
on android (linux)
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
18 matches
Mail list logo
