similar to: [LLVMdev] generating src code along with LLVM assembly from byte code

Hi all, I am trying to disassemble *.bc to assemble code by using llvm-dis command, but what I got is like the following. So how could I get the assemble code like objdump? I mean the memory address for each instruction. Thanks Qiuyu llvm-dis: .text .align 16 .globl adpcm_coder .type adpcm_coder, @function adpcm_coder: .LBBadpcm_coder_0: # entry sub %ESP, 116 mov DWORD PTR [%ESP + 12],

On Oct 12, 2010, at 4:28 PM, shankha <shankhabanerjee at gmail.com> wrote: > Hi, > If I convert global variables to thread-local variables or vice versa > at the IR stage do I have to take care of the debug metadata. If you provide an small concrete example then it would help, Devang > I looked at the IR generated and I couldn't find any difference > between the debug

Hi, If I convert global variables to thread-local variables or vice versa at the IR stage do I have to take care of the debug metadata. I looked at the IR generated and I couldn't find any difference between the debug metadata generated for global variables and thread-local variables. -- Thanks Shankha

Hi Devang, I convert all global variables in a file to thread local at the IR level. i.e. compile example_llvm.c to IR example_llvm.ll and change global variables to thread-local variables. I also insert a function call just before access of the global(now thread-local) variable. I also insert a local variable in main. Does these operations in any way effect the debug metadata ? I do not face

Thanks John and Chris. I could get the address information by the way you guys mentioned. But it is not what I want, because it will lose information about the entry of basic block. Actually what I want to get is the address of each entry of basic block. Now I am trying to declare the label of basic block as global type, hopefully I can get it from symbol table. Can I get it by this way? Thanks

Hi Devang, Is there any particular reason as to why debug info support for tls hasn't been implemented. Is the feature in pipeline ? How hard is it to implement ? On Wed, Oct 13, 2010 at 4:12 PM, Devang Patel <dpatel at apple.com> wrote: > > On Oct 13, 2010, at 10:09 AM, shankha wrote: > > Hi Devang, > > On Wed, Oct 13, 2010 at 12:44 PM, Devang Patel <dpatel at

On Tue, Nov 6, 2012 at 2:19 PM, Marshall Clow <mclow.lists at gmail.com> wrote: > Binutils and LLVM > > As part of "owning our own toolchain", various people have expressed an interest and have been working on creating various tools that duplicate the functionality of tools available on other systems. > > As a start, I'd like to summarize the current status, and

Hi Devang, On Wed, Oct 13, 2010 at 12:44 PM, Devang Patel <dpatel at apple.com> wrote: > In your example, you do not need to update debug info for @global_var at the moment. We are not identifying tls in debug info yet. Does that mean I will not be able to debug applications which use tls through gdb if they are build with gcc-lllvm or clang. > On Oct 13, 2010, at 8:30 AM, shankha

Shankha, AFAIK, nobody is actively working on debug info for TLS at the moment. On Oct 13, 2010, at 3:19 PM, shankha wrote: > Hi Devang, > Is there any particular reason as to why debug info support for tls > hasn't been implemented. > Is the feature in pipeline ? How hard is it to implement ? - Devang

On Oct 13, 2010, at 10:09 AM, shankha wrote: > Hi Devang, > > On Wed, Oct 13, 2010 at 12:44 PM, Devang Patel <dpatel at apple.com> wrote: >> In your example, you do not need to update debug info for @global_var at the moment. We are not identifying tls in debug info yet. > > Does that mean I will not be able to debug applications which use tls > through gdb if they

If I use the jump threading pass on the attached IR: $ opt before.ll -jump-threading -o - | llvm-dis -o after.ll a big chunk gets removed, a chunk that is actually necessary. ('before.ll' passes the test in webkit, while 'after.ll' fails) Can someone take a look ? -Argiris -------------- next part -------------- A non-text attachment was scrubbed... Name: before.ll Type:

Hi, Tanya M. Lattner wrote: >> We were wondering if *all* of the dejagnu tests should pass (in the >> sense that no result should be unexpected), because we have a few failed >> tests on our build. > > make check should always be clean. However, sometimes people do commit > changes that impact platforms they are not able to test on and we do have > the occasional

Hi all, I am doing emulation on a custom processor. For this I need hexcode for the C application program . Is there any llvm command/function that can spit out the hexcode just like objdump in gcc? Thanks -- View this message in context: http://old.nabble.com/hexcode-from-llvm-tp28612686p28612686.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

On Wed, 28 Jul 2004, Reid Spencer wrote: > 2. MODE OF OPERATION > ==================== > The driver will simply read its command line arguments, read its > configuration data, and invoke the compilation, linking, and > optimization tools necessary to complete the user's request. Its basic I'm not sure that I agree with this. Compilers need to be extremely predictable and

On Jul 1, 2008, at 10:11 AMPDT, Edd Barrett wrote: > Hi, > > Tanya M. Lattner wrote: >>> We were wondering if *all* of the dejagnu tests should pass (in the >>> sense that no result should be unexpected), because we have a few >>> failed >>> tests on our build. >> >> make check should always be clean. However, sometimes people do

On May 19, 2010, at 12:01 PM, JayaSus wrote: > > Hi all, > > I am doing emulation on a custom processor. For this I need hexcode for the > C application program . Is there any llvm command/function that can spit out > the hexcode just like objdump in gcc? > Hi JayaSus, I'm confused by your question. Do you mean the LLVM IR "object code" or the resulting

Binutils and LLVM As part of "owning our own toolchain", various people have expressed an interest and have been working on creating various tools that duplicate the functionality of tools available on other systems. As a start, I'd like to summarize the current status, and ask people for help updating the list. List taken from <http://www.gnu.org/software/binutils/>

On Mon, Sep 23, 2013 at 07:48:45PM -0400, Sean Silva wrote: > I like the idea, but I find the name confusing; I think it should have > `llvm-c` or `c-api` somewhere in the name. This could also serve as a > simple example of using the API. I had it as llvm-c-test first, then noticed that the shared library's directory was named "llvm-shlib". Yes, making sure it serves as

Dear llvm developpers, I followed the tutorial to build llvm and clang provided here: https://clang.llvm.org/get_started.html The sources are in sync with subversion repository, and I ended up with more than 30GB of binaries in llvm/bin as shown at the end of this message. I assume I did something wrong, but I did not find any entry in the doc that helps me understand how to reduce the size of

In your example, you do not need to update debug info for @global_var at the moment. We are not identifying tls in debug info yet. On Oct 13, 2010, at 8:30 AM, shankha wrote: > I do not face any issues debugging my test case. But while debugging > my application > through gdb I cannot make sense of the call stack. I do not see the > function names in > the call stack (with or