clang+llvm-3.8.0-rc3-x86_64-linux-gnu-debian8.tar.xz (sha1sum:
2dedc6136d7cfbac8348652c543887964d92393c)
Native: All ok
Cross compiling to MIPS: All ok
clang+llvm-3.8.0-rc3-mips-linux-gnu.tar.xz (sha1sum:
f286149dbb2ea7e194c5c3719b6cded476f6e65f)
All ok (aside from non-re
> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev
> wrote:
>
> Hi,
>
> I am trying to listen for module/symbol load/unload events and display them
> in output UI so that debugger users can have a basic clue what is debugger
> busy doing while launching a big executable linking many sha
> On Feb 28, 2016, at 2:17 PM, Paul Peet wrote:
>
> Hey,
>
> Just to let you know that I think I made some progress in determine the
> problem.
> I've basically setup an vm (archlinux, linux 4.4, lldb 3.7.1) and
> tried the code on it. To my surprise it gave me proper output without
> non-dete
This is very useful, thanks for the info!
On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham wrote:
>
> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi,
>
> I am trying to listen for module/symbol load/unload events and display
> them in output UI so th
Hello, fellow developers and congratulations with long awaited 3.8 Release.
I wonder why AArch64 stripped binary of lldb-server built from [3.8 Release]
RC3 source is so much bigger than its ARM counterpart.
See the numbers:
16318632 Feb 29 22:41 lldb-server-3.8.0-aarch64
9570916 Feb 29 22:23 ll
In general where you see the event bits defined like SBTarget.h for your case,
the class that contains the event bit definitions:
class SBTarget
{
public:
//--
// Broadcaster bits.
//--
I see why I did not find them in the first place. These two APIs are not
listed in the official doc:
http://lldb.llvm.org/python_reference/index.html
Someone might want to add it.
Thanks
Jeffrey
On Mon, Feb 29, 2016 at 11:59 AM, Jeffrey Tan
wrote:
> This is very useful, thanks for the info!
>
Greg, missed your reply. Yeah, the problem is that I only looked at the
python API(which is what I am using) doc which does not contain these APIs.
On Mon, Feb 29, 2016 at 12:43 PM, Greg Clayton wrote:
> In general where you see the event bits defined like SBTarget.h for your
> case, the class t
Btw: I did not find an API to retrieve the load address of the SBModule?
This seems to be weird to me, did I miss anything?
On Mon, Feb 29, 2016 at 1:34 PM, Jeffrey Tan
wrote:
> I see why I did not find them in the first place. These two APIs are not
> listed in the official doc:
> http://lldb.
There isn’t necessarily A load address for an SBModule. After all, the
different segments could load with different offsets. We usually list the
offset of the __TEXT__ address as the load address - for instance in “image
list", since if you are only interested in symbolication, that’s what you
As Jim said there really isn't just one address per module. You will want to
display the address of each of the sections for a module under that module. So
something like:
a.out
|- .text @ 0x1
|- .data @ 0x2
\- .bss @ 0x3
> On Feb 29, 2016, at 2:02 PM, Jeffrey Tan wrote:
>
Suppose you've got two line sequences.
First sequence:
4198512
4198544
4198547
4198562
Second sequence:
4198528
4198531
4198537
4198552
These two line sequences overlap, and will not be inserted correctly into a
LineTable. This sounds like a bug to me, because as far as I can tell
there is noth
> On Feb 29, 2016, at 5:09 PM, Zachary Turner wrote:
>
> Suppose you've got two line sequences.
>
> First sequence:
> 4198512
> 4198544
> 4198547
> 4198562
>
> Second sequence:
> 4198528
> 4198531
> 4198537
> 4198552
>
> These two line sequences overlap, and will not be inserted correctly i
Those are addresses. Here's the situation I was encountering this on:
// foo.h
#include "bar.h"
inline int f(int n)
{
return g(n) + 1;
}
// bar.h
inline int g(int n)
{
return n+1;
}
// foo.cpp
#include "foo.h"
int main(int argc, char** argv)
{
return f(argc);
}
PDB gives me back li
On Mon, Feb 29, 2016 at 5:49 PM Zachary Turner wrote:
> Those are addresses. Here's the situation I was encountering this on:
>
> // foo.h
> #include "bar.h"
> inline int f(int n)
> {
> return g(n) + 1;
> }
>
> // bar.h
> inline int g(int n)
> {
> return n+1;
> }
>
> // foo.cpp
> #includ
On Mon, Feb 29, 2016 at 2:20 AM, Daniel Sanders
wrote:
> clang+llvm-3.8.0-rc3-x86_64-linux-gnu-debian8.tar.xz (sha1sum:
> 2dedc6136d7cfbac8348652c543887964d92393c)
> Native: All ok
> Cross compiling to MIPS: All ok
>
> clang+llvm-3.8.0-rc3-mips-linux-gnu.tar.xz (sha1sum:
> f28614
My assumption is that different sections of the binary will be mapped
continuously in memory; and the first section(which should be a header
section for the binary) will stands for the base address of the whole
module.
Is this assumption not true for all platforms? Basically, I would like to
show t
17 matches
Mail list logo
