similar to: [DebugInfo] DWARF C API

Hi David, Sorry, I forget to attach the valgrind dump to this. I was not sure if my implementation was ok, so I wanted to ask if I've done something wrong first. Process terminating with default action of signal 11 (SIGSEGV) Access not within mapped region at address 0xB at 0x54F4516: llvm::object::COFFObjectFile::moveSectionNext(llvm::object::DataRefImpl&) const

Hi I come across the following exception when I use the llvm-dwarfdump -debug-info target_binary: llvm-dwarfdump: /home/linux/llvm-7/llvm/lib/MC/MCRegisterInfo.cpp:87: int llvm::MCRegisterInfo::getLLVMRegNum(unsigned int, bool) const: Assertion `I != M+Size && I->FromReg == RegNum && "Invalid RegNum"' failed. Stack dump: 0. Program arguments:

Hi Dave I am not going to access any hardware. I am using clang to analysis the ARM binaries. The binary is 483.xalancbmk in CPU SPEC2006. When I use the optimization O0, no crash will occur. The crash occurs when I set optimization level as O1,O2,O3 and Os. If I have to recompile and rerun the tests. What version of llvm is suggested. It would be better if anyone could provide the patch on this

Hi Dave Sorry, I meant the hardware you're using to compile LLVM - you mentioned it took you a long time to rebuild it so it would be hard for you to write/experiment on tests. ============================= Compiling LLVM doesn't take me too much time(less than 2 hours). The hardware is good enough and I am using interl E5 CPU. What I mean is that it took me a long time to analysis the

On 06.11.2020 13:32, James Henderson wrote: > Hi Alexey, > > On Thu, 5 Nov 2020 at 21:02, Alexey Lapshin <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > Hi James, > > On 05.11.2020 17:59, James Henderson wrote: >> (Resending with history trimmed to avoid it getting stuck in >> moderator queue). >>

Hi James, On 05.11.2020 17:59, James Henderson wrote: > (Resending with history trimmed to avoid it getting stuck in moderator > queue). > > Hi Alexey, > > Just an update - I identified the cause of the "Generated debug info > is broken" error message when I tried to build things locally: the > `outStreamer` instance is initialised with the host Triple,

Hi, While dogfooding our lldb based IDE on Linux, I am seeing a lot of variable evaluation errors related to DW_TAG_member which prevents us from release the IDE. Can anyone help to confirm if they are known issues? If not, any information you need to troubleshoot this issue? Here is one example: (lldb) fr v *error: biggrep_master_server_async 0x10b9a91a: DW_TAG_member '_M_pod_data'

If you're going to use clang built binaries with lldb, you'll want to pass -fstandalone-debug - this is the default on platforms where lldb is the primary debugger (Darwin and freebsd) Not sure if that is the problem you are seeing, but will be a problem sooner or later On Mar 26, 2016 4:16 PM, "Jeffrey Tan via llvm-dev" <llvm-dev at lists.llvm.org> wrote: > Hi, >

Thanks David. I meant to send to lldb maillist, but glad to hear response here. Our binary is built from gcc: String dump of section '.comment': [ 1] GCC: (GNU) 4.9.x-google 20150123 (prerelease) Is there any similar flags we should use? By doing "strings -a [binary] | grep -i gcc", I found the following flags being used: GNU C++ 4.9.x-google 20150123 (prerelease)

For llvm-dwarfdump we need to handle relocations inside the debug info sections in order to successfully dump the dwarf info including strings. Nick sent out a partial patch that did this not too long ago and I've taken it and gone in a bit of a different direction, but kept the same basic architecture. In place of applying the relocations to the data we've read from disk I'm keeping

On Mon, Nov 5, 2012 at 5:17 PM, Eric Christopher <echristo at gmail.com> wrote: > For llvm-dwarfdump we need to handle relocations inside the debug info > sections in order to successfully dump the dwarf info including strings. > Nick sent out a partial patch that did this not too long ago and I've taken > it and gone in a bit of a different direction, but kept the same basic

On Sat, Mar 26, 2016 at 11:31 PM, Jeffrey Tan <jeffrey.fudan at gmail.com> wrote: > Thanks David. I meant to send to lldb maillist, but glad to hear response > here. > > Our binary is built from gcc: > String dump of section '.comment': > [ 1] GCC: (GNU) 4.9.x-google 20150123 (prerelease) > > Is there any similar flags we should use? > If it's