[Lldb-commits] [PATCH] D130805: [trace][intel pt] Support a new kernel section in LLDB’s trace bundle schema

[Sujin Park via Phabricator via lldb-commits]

persona0220 marked 7 inline comments as done.
persona0220 added inline comments.


================
Comment at: lldb/source/Plugins/Trace/intel-pt/TraceIntelPTConstants.h:25
 const bool kDefaultDisableCgroupFiltering = false;
+const uint64_t kDefaultKernelLoadAddress = 0xffffffff81000000;
 
----------------
jj10306 wrote:
> wallace wrote:
> > 
> a couple questsions here:
> 1. where is this value coming from? Would be useful to provide a link to documentation
> 2. does this depend on the system?
> 3. I know you and @wallace were discussing the implications of ASLR offline, but curious what will happen if this load address is not correct due to ASLR or any other reason. Do we have a way to detect this?
1. It's the address of startup_64, the start address of loaded kernel image. This is a good documentation https://0xax.gitbooks.io/linux-insides/content/Theory/linux-theory-2.html
2. It depends on architecture, and this is for x86. Thus, user can skip "loadAddress" section in "kernel" section in x86, and for other architecture, they have to specify the loadAddress.
3. This is a good question! We don't have a logic to detect it yet. What I can come up roughly is analyzing the given elf file with load address and check whether it's valid?


================
Comment at: lldb/source/Plugins/Trace/intel-pt/TraceIntelPTConstants.h:25
 const bool kDefaultDisableCgroupFiltering = false;
+const uint64_t kDefaultKernelLoadAddress = 0xffffffff81000000;
 
----------------
wallace wrote:
> persona0220 wrote:
> > jj10306 wrote:
> > > wallace wrote:
> > > > 
> > > a couple questsions here:
> > > 1. where is this value coming from? Would be useful to provide a link to documentation
> > > 2. does this depend on the system?
> > > 3. I know you and @wallace were discussing the implications of ASLR offline, but curious what will happen if this load address is not correct due to ASLR or any other reason. Do we have a way to detect this?
> > 1. It's the address of startup_64, the start address of loaded kernel image. This is a good documentation https://0xax.gitbooks.io/linux-insides/content/Theory/linux-theory-2.html
> > 2. It depends on architecture, and this is for x86. Thus, user can skip "loadAddress" section in "kernel" section in x86, and for other architecture, they have to specify the loadAddress.
> > 3. This is a good question! We don't have a logic to detect it yet. What I can come up roughly is analyzing the given elf file with load address and check whether it's valid?
> Just like the comment I left below, I think it's better not to have this default value here because it's not guaranteed to work on every system.
> 
> What we can implement in the collector is the following:
> 
> read /proc/kcore and look for the line with the entry `SYMBOL(_stext)=ffffffff81000000`
> 
> then in the documentation we can mention that this a way to get this load address, and we can implement that in the collector
As we discussed offline, kernel load address is always set to [ffffffff81000000 for x86](
https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/Documentation/x86/x86_64/mm.txt#L21), so I'll keep default value and accept an optional load address.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130805/new/

https://reviews.llvm.org/D130805