Displaying 20 results from an estimated 10000 matches similar to: "LLVM dwarf info is not complete"
2018 May 22
0
LLVM dwarf info is not complete
> On May 22, 2018, at 8:06 AM, Muhui Jiang via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> Hi
>
> I am using llvm-dwarfdump to dump the line table with -debug-line option. I compiled my program with -gdwarf-3.
>
> I first get the line number and source number for every instruction of the LLVM IR with metadata. Then I try to find the corresponding binary address
2018 Jun 01
3
Function start address
Hi
I am using LLVM Pass combined with dwarf debug information to get all the
function's start address. My steps are below:
First, I write the function pass to get the start line of each function,
which is finished.
Then, based on the start line of every single function, I try to query the
specific line from the dwarf's line binary table, which is generated with
llvm-dwarfdump
2018 Jun 02
2
Function start address
Hi
Actually, No particular reason. I just think this might be a solution, then
I use think kind of method. Querying the symbol table would be a good
choice, but I prefer to use LLVM and dwarf information. I am sorry that I
am not familiar with debug_info. But thanks to your suggestions. I would
like to try to solve it with debug_info. It seems work according to your
comments
By the way, I am
2018 Jun 26
2
Instruction boundaries
There should be a line-table entry for the end of the function, which appears to be missing from the dump you provided. llvm-dwarfdump should report this address with 'end_sequence' in the Flags. Are you using a different dumper?
I am not sure but my guess would be that inline data is not represented in the line table. The line table's primary purpose is to inform the debugger
2018 Jun 26
2
Instruction boundaries
I'm not familiar with the target instruction set, but if "MOV PC, R0" is not a return instruction, I'm guessing that the sequence starting at A39C is a dispatch through a jump table. The jump table would be considered part of the instruction stream and included in the scope of the line table. This is not a case where you would see end_sequence; my mistake.
The line table does
2018 Nov 03
2
llvm bug 36466 fix
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
2018 Nov 03
2
llvm bug 36466 fix
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
2018 Jun 26
2
Instruction boundaries
Hi paulr
Thanks for your reply. Though DWARF info give me the code address ranges,
there might be inline data. If so, how to handle this case?
As for the dwarf line table. Sometimes, the source line might be zero. Do
you know why? If all instructions should be describe in the line table, I
think analyzing Dwarf line table is enough to get all the instructions
addresses. Do you agree?
I would
2018 Nov 03
2
llvm bug 36466 fix
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:
2018 May 16
1
clang dwarf
Hi
I am building the llvm IR to generate the control flow graph. I am using
autotools(configure, make) to compile my whole program. I use the
-save-temps option to save the llvm IR. Now I would like to generate a
control flow graph on binary level. I may need the dwarf information to
know the mapping between source code and binary code. Besides, I may also
need to know the relationship between
2018 Jun 13
2
IR to binary address mapping
Hi Paul
Thanks for your comments. Suppose I can generate the control flow graph via
LLVM Pass or the default option like '-dot-cfg' with opt. However, the
control flow graph is based on llvm IR level. I would like to have a
control flow graph based on binary level. Thus, I want to map the IR to
binary address.
As far as I know, we used to use the debug information to map the IR to
source
2018 Jun 12
4
IR to binary address mapping
Hi
I know that LLVM provide some debug API for us to know the source code
information. For example, every IR instruction's source line number and
column number.
However, are there any method to get a mapping from IR instruction to
binary address directly. I don't want to use dwarf line mapping table as a
bridge. I think the binary is generated by clang and llvm. I think there
definitely
2018 Jun 25
2
Instruction boundaries
Hi
I was wondering whether there are any methods to know what part of the
target binary is code.
I have some ideas and hope to get your comments.
I would like to use LLVM's source level debugging information to extract
the source lines belonging to every functions. Then use the dwarf mapping
table to transfer the source level information to binary address. Are
there any better methods?
2018 Jun 13
2
IR to binary address mapping
Hi
However, frontend may also do various operations on the source code and one
line number and column number could map to more than one binary address.
Why LLVM IR cannot?
Regrads
Muhui
2018-06-12 23:18 GMT+08:00 mayuyu.io <admin at mayuyu.io>:
> In theory that’s not exactly possible/accurate. Due to various operations
> in the Backend like Instruction Legalization, one IR
2018 Sep 29
2
Function Signature
Hi
I was wondering whether I can extract the function signature from the dwarf
debugging information or symbol table. I mean the argument list and the
return variables.
I know that in dwarf debugging information, a subprogram represents a
function. However, I could not find the information that is related to the
function signature. Any ideas? Many Thanks
Regards
Muhui
-------------- next part
2018 Sep 05
2
AddressSanitizer on SPECCPU2006
Hi Alex
Thanks for your email. But it seems not work. I removed the
-fsanitize=address flag.
The global buffer overflow message doesn't show. However, no *.sancov file
is created after I run perlbench. Thus, I could not get the BB coverage. Do
you have any ideas? Many Thanks
Regards
Muhui
Alexander Potapenko <glider at google.com> 于2018年9月5日周三 下午7:14写道:
> Hi Muhui,
>
> If
2018 Sep 05
2
AddressSanitizer on SPECCPU2006
Hi
If so, is it able to disable this check. All I need is just to get the BB
coverage information
Regards
Muhui
Alexander Potapenko <glider at google.com>于2018年9月5日 周三下午6:57写道:
> This is a known problem in SPECCPU2006, see
> https://github.com/google/sanitizers/wiki/AddressSanitizerFoundBugs
> On Wed, Sep 5, 2018 at 7:36 AM Muhui Jiang via llvm-dev
> <llvm-dev at
2018 Jun 28
2
Distinguish between ARM and Thumb
Hi
Nowadays I am using LLVM to do ARM binary analysis. I was wondering is llvm
available to provide some debugging information on the mode of ARM.
For example, llvm-dwarfdump could dump some instructions information for
debugging. Is it able to know the mode for each instruction? Or we may
write some llvm pass to help us to know the instruction mode? Any
suggestions are welcomed. Many Thanks
2018 Sep 05
2
AddressSanitizer on SPECCPU2006
Hi
I am using SanitizerCoverage feature supported by clang to get the
basicblock coverage.
my tested binaries are spec cpu2006. I compiled the binary with the option
COPTIMIZE = -O0 -fsanitize=address -fsanitize-coverage=bb -flto
-fno-strict-aliasing -std=gnu89 -gdwarf-3
After the compiling process is end. I run the 400.perlbench. with the
command
ASAN_OPTIONS=coverage=1 ./perlbench.
2011 Mar 17
2
[LLVMdev] Writing unit tests for DWARF?
On Mar 17, 2011, at 8:44 AM, Renato Golin wrote:
>> dwarfdump --verify will do this.
>
> Is this being used in LLVM tests? This is an idea.
It is not used in llvm/test tests.
> I had a look at your debug tests in clang and they're similar to what I do here.
>
> The problem with debug tests is that it doesn't depend only on the
> compiler, but on the debugger