Re: [lldb-dev] How to load core on a different machine? - image base addresses
> On Jan 7, 2016, at 9:02 AM, Eugene Birukov wrote: > > Forking the thread since image list looks like an independent issue. > > • There is no image base addresses on Linux. Is this a known issue? It is now! > • I did not find any C++ API to get it in my program. Did I miss it? > Seems useful... The main question is what do you consider to be your "image address"? For MachO files on MacOSX, it is the address of the mach header in memory. If the ELF header and all of the program headers and sections headers are actually in memory, then the address should be the address of the ELF header. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] How to load core on a different machine? - image base addresses
> On Jan 7, 2016, at 9:48 AM, Eugene Birukov wrote: > > > It is now! > > Good :). Any plans to fix it? I guess I should just file a bug, right? > Please file a bug. Someone probably will from the linux community, possibly even you? > > The main question is what do you consider to be your "image address"? > > I need the address that I feed to SBTarget::SetModuleLoadAddress() if I load > modules manually. > > I iterated over module sections. As I understand, the base address is > 0x7fc7125ff000. I verified it by really calling SetModuleLoadAddress() and > looking at stacks that LLDB produces. But to find it programmatically I'll > need to do some math: pick any section with non-zero size and subtract its > file address form its memory address. Hmm... seems like a workaround, but it > would be better to have a more direct way. > > (x86_64) /home/eugene/joe/so/libjemalloc.so.1 > 0x [0x-0x) libjemalloc.so.1. > 0x7fc7125ff200 [0x0200-0x0224) > libjemalloc.so.1..note.gnu.build-id > 0x7fc7125ff228 [0x0228-0x0328) > libjemalloc.so.1..gnu.hash > 0x7fc7125ff328 [0x0328-0x0b08) > libjemalloc.so.1..dynsym > 0x7fc7125ffb08 [0x0b08-0x0f01) > libjemalloc.so.1..dynstr > 0x7fc7125fff02 [0x0f02-0x0faa) > libjemalloc.so.1..gnu.version > 0x7fc7125fffb0 [0x0fb0-0x1040) > libjemalloc.so.1..gnu.version_r > 0x7fc712600040 [0x1040-0x2c00) > libjemalloc.so.1..rela.dyn > 0x7fc712601c00 [0x2c00-0x3008) > libjemalloc.so.1..rela.plt > 0x7fc712602008 [0x3008-0x3022) libjemalloc.so.1..init > 0x7fc712602030 [0x3030-0x32f0) libjemalloc.so.1..plt > 0x7fc7126022f0 [0x32f0-0x000286fa) libjemalloc.so.1..text > 0x7fc7126276fc [0x000286fc-0x00028705) libjemalloc.so.1..fini > 0x7fc712627740 [0x00028740-0x0002a344) > libjemalloc.so.1..rodata > 0x7fc712629344 [0x0002a344-0x0002afa0) > libjemalloc.so.1..eh_frame_hdr > 0x7fc712629fa0 [0x0002afa0-0x0002fdcc) > libjemalloc.so.1..eh_frame > 0x7fc71282f710 [0x00230710-0x00230714) libjemalloc.so.1..tdata > 0x7fc71282f718 [0x00230718-0x00230748) libjemalloc.so.1..tbss > 0x7fc71282f718 [0x00230718-0x00230728) > libjemalloc.so.1..init_array > 0x7fc71282f728 [0x00230728-0x00230730) > libjemalloc.so.1..fini_array > 0x7fc71282f730 [0x00230730-0x00230738) libjemalloc.so.1..jcr > 0x7fc71282f740 [0x00230740-0x00231d70) > libjemalloc.so.1..data.rel.ro > 0x7fc712830d70 [0x00231d70-0x00231f70) > libjemalloc.so.1..dynamic > 0x7fc712830f70 [0x00231f70-0x00232000) libjemalloc.so.1..got > 0x7fc712831000 [0x00232000-0x00232170) > libjemalloc.so.1..got.plt > 0x7fc712831180 [0x00232180-0x00232209) libjemalloc.so.1..data > 0x7fc712831220 [0x00232220-0x002334b0) libjemalloc.so.1..bss > 0x [0x-0x) > libjemalloc.so.1..gnu_debuglink > 0x [0x-0x) > libjemalloc.so.1..shstrtab So try the following: (lldb) memory read 0x7fc7125ff000 See if you see the "ELF\x7d" magic byte string. If so, then this is definitely the address you are looking for. You can also set a breakpoint when the shared libraries get loaded and see where the image is being loaded since I believe the POSIX Dynamic Loader loads things using a single address that it gets from somewhere. This address that is used by the dynamic loader should be the address that is displayed... Greg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb status at windows
Feel free to file bugs or post your feedback here after you use about what worked, what didn't work, what's missing, etc. Anything that doesn't work is a bug that I would like to fix. On Thu, Jan 7, 2016 at 10:02 AM Zachary Turner wrote: > Hi, I guess I should make a new blog post at some point, or post status on > the website. Here's my best estimate at what you can expect. > > * Most common debugging scenarios should work. Run under debugger, attach > to process, interrupt, continue, print variable values, evaluate > expressions, etc. > * Step-over might be unstable in certain scenarios > * Conditional breakpoints don't work > * Hardware watchpoints don't work > * Expression evaluation might not work in some advanced cases. > > The main big feature that has been added since the original blog post is > support for windows minidump files. So you can create a minidump of a > stopped process from inside LLDB, and you can load up a minidump and do > post-mortem debugging. > > On Wed, Jan 6, 2016 at 10:39 PM Red Skotina via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Where can i look lldb status for native debug at Windows? >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] clang-format now supports return type on separate line
As far as I'm aware, this is the last major incompatibility between LLDB's style and clang-format's feature set. I would appreciate it if more people could try it out with a few of their patches, and let me know if any LLDB style incompatibilities arise in the formatted code. I would eventually like to move towards requiring that all patches be clang-formatted before committing to LLDB. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb status at windows
Nice to hear. I should answer after some time of using 2016-01-07 21:04 GMT+03:00 Zachary Turner : > Feel free to file bugs or post your feedback here after you use about what > worked, what didn't work, what's missing, etc. Anything that doesn't work > is a bug that I would like to fix. > > On Thu, Jan 7, 2016 at 10:02 AM Zachary Turner wrote: > >> Hi, I guess I should make a new blog post at some point, or post status >> on the website. Here's my best estimate at what you can expect. >> >> * Most common debugging scenarios should work. Run under debugger, >> attach to process, interrupt, continue, print variable values, evaluate >> expressions, etc. >> * Step-over might be unstable in certain scenarios >> * Conditional breakpoints don't work >> * Hardware watchpoints don't work >> * Expression evaluation might not work in some advanced cases. >> >> The main big feature that has been added since the original blog post is >> support for windows minidump files. So you can create a minidump of a >> stopped process from inside LLDB, and you can load up a minidump and do >> post-mortem debugging. >> >> On Wed, Jan 6, 2016 at 10:39 PM Red Skotina via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >>> Where can i look lldb status for native debug at Windows? >>> ___ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> >> ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Just a reminder, LLVM bay-area social tonight at 7pm
Location is Tied House as usual. Feel free to follow and RSVP here: http://www.meetup.com/LLVM-Bay-Area-Social/events/226284610/ ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
