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
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
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
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 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
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
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:
>
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
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.
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
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!
>
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.
//--
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
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
> 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
> 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
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
17 matches
Mail list logo
