Ratonland Menu
Login 
|
| DWARF 2 Debugging Information | | Posted by bleader -- Monday 12th of June 2006 08:27:15 AM | DWARF2 debugging information format
Summary- Basics
- Data Structures
- Data Types
- Need more information?
- Appendix
Introduction :
In this article I'll try to explain a bit how to use the DWARF 2 to get debugging information. Nothing in this article is given for sure, I'll do my best just to enable people to get some more information if they want to use this format. Those of you who have read the official documentation will understand why I won't say that I'm sure I got it right. The format is a binary format, with a very few fixed size data, and the documentation is not really easy to understand.
I'll only talk about it in ELF binary generated from C/C++ code by for example gcc. The DWARF 2 is written and made to be really portable to any language, unfortunately for you if you're searching for help about something else I won't be able to help you.
What you will need to understand is mainly the organisation of the data. When you got it, it's not that hard, but at first sight, it may be a little frightening.
You should have at disposal a compiler able to generate DWARF 2 debugging information (like gcc), readelf, an hexadecimal editor of your choice (hexedit is pretty cool, except his help is bind on my "launch urxvt" binding :).
You can have a look at the --debug-dump option in readelf's manpage, that may be a great help.
Remember that gcc under *BSD seems to be generating stabs information if you don't force it to dwarf with the '-gdwarf-2' option. Under linux -g will generate DWARF2 information.
A little knowledge about the organisation of ELF binaries may be a good help even if you may be able to get the main point without it.
For sources, you can have a look at readelf (can be found in binutils), or the libdwarf, coming along with a dwarf-dump program. I don't really found it usefull as the code is pretty unbereable to me, but it's still one of the rare programs reading DWARF 2 information. Finally you can have a look at the gdb sources, but it's a little big and not always easy to follow. Hope that you'll find something to help you out with this little list.
Basic principles :
All information in DWARF 2 are stored in binary, except for strings of course.
That means that compared to stabs, you won't have to do parsing, the real hard part of DWARF 2 is to understand how it works, not to parse a strange text format (people who tried to read stabs information know what I mean :)
When a binary is compiled with DWARF 2 debugging information, those information are stored in sections of the ELF binary. The two main sections you'll need are:
- .debug_info
- .debug_abbrev
I may refer to those as abbrev table, info table, info, abbrev, I'll try to not screw up too much with the names :)
Those two sections are extremly close to each other (in term of use, not especially in memory space), and are both needed to get DWARF 2 information.
As soon as the binary get a little bigger, or there are multiple files compiled (which is almost always the case), you'll get another section named :
- .debug_str
This one will only contain null terminated strings, they will be used to lighten the content of the info section, and to avoid redundant information. We will see how this is done further in this document.
In thoses sections you will be able to find some basic information like:
- name of the compiled file
- name of the compiler
- functions, return type and parameters
- types
- variables
More information are available in the DWARF 2 format, like line numbers, functions addresses and much more, but you will need to use other sections:
- .debug_lines
- .debug_aranges
- .debug_pubnames
- .debug_frame
For now this document will focus on the information in info abbrev and str sections, somewhat the basics.
Getting sections :
As I've said before, info et abbrev are used together to get the information. You will have to find the address of the right section in the binary file.
I'll explain how I made it in our project where I used DWARF 2 information. Once again this is not the only way or even the best way to do this, I'm just telling my own experience in hope that it could be usefull to someone.
What I did was like this :
- mapping binary file
- reading ELF information
- stocking a linked list of section headers
- finding sections headers for DWARF 2
- for each sections header:
|--> get offset
|--> add it to mappeed binary address to have where it start
|--> store this address
|--> store section size
For each sections I kept :
- base address
- current address
- size
This was made really easy to do as emp made a library for this project which was helping out do all the ELF work.
As you will see, you can't just read and that's ok, to read DWARF 2 information you will alway be reading forward in the sections, and unless you keep a giant list of what you've read and in which order, you won't be able to go back.
As it's all in binary format, any mistake will be a pain in the ass to debug, you will have to print lots of information and compare them with the binary file in an hexadecimal editor, or have a look at the values that readelf may show you.
At the beginning it is probably a good idea to follow step by step what you read with the binary opened in an hexadecimal editor.
You'd better get familiar with the ELF section, offsets found with readelf so that you may find back the right addresses quickly.
Having a fixed binary that you won't recompile, and make tests on it is a pretty good idea, you will soon know the addresses you need in the binary and won't have to search for it. But be warned : try on other binaries too, maybe mistakes can slips in your code, and won't show up when testing on your main test binary (yep, it happened to me :/).
Organization :
In this section I'll try to explain how the data are organized in the sections used by the DWARF 2 format. As I haven't talk about the types yet this will probably be a bit abstractive of some explanations. But as types contain refecences in sections, you will need to understand the data's organization before.
As I've already told earlier, info and abbrev are used in bundle, that is to say you will need to understand both, and how they are linked together.
Unfortunatelly it's pretty complicated just to explain each section, that's why I won't try to explain both at the same time.
If you've followed the beginning of this documentation, you already know how to get the sections addresses. Here is the main organization of the info section:
There is no main header, you'll directly find a header that will refer to the first Compilation Unit (I'll call them CU from now on).
What is a CU ? It's a part of the DWARF information that will only refer to one "object" or in most cases, one compiled file. Most of the time you will find in a CU those kind of information :
- file name
- path where it was compiled
- compiler name
- types defined in included headers
- basics types used in this files (only those used)
- functions and their return type
- parameters name and type
That's all that come to my mind at the moment, but that is not an exhaustive list.
As you've seen in Fig-1 the info section is a concatened list of bundles header-CU. What this header looks like anyway ? Here it is:
- CU length : 32bits
- DWARF version : 16bits
- abbrev offset : 32bits
- pointer size : 8bits
That is a total of 11 bytes. This is the only fixed size thing you'll have in DWARF 2 as far as I know :).
Warning
The first thing you'll think of is probably making a nice structure and then point it to the address. There are two fallback to this:
Problem :
If you're not on x86 you will surely have alignement problems. That goes for the whole DWARF 2. As sizes or not fixed, nothing will be aligned, on x86 you can point and read everywhere on your mapped binary, but as soon as you switch to sparc or ia64, that won't be nice.
Solution :
The best method is probably to memcpy as this is dependant of the system and is hopefully done to avoid bus error and alignement problems.
That goes for the whole DWARF 2, you'll have to read data that will most of the time won't be aligned. It is probably a good idea to always memcpy the data and work on the copy.
Problem :
Compiler packs structures by default. That is to say if you made a structure like int, short, int, char for this case, it won't use 11 bytes, but 16. Pointing or copying the data from the start of .debug_info to your structure won't do the trick as it will write in the padding left by the compiler.
Solution :
There is a "#pragma pack" directive that may be used to do this.
The best way to learn about it is probably to search for it on the web.
By the way here is the first google result about it at the time of this writing.
Let's get back to the CU header.
- CU length : 32bits
- DWARF version : 16bits
- abbrev offset : 32bits
- pointer size : 8bits
The Length will let you know how long will the CU be without the 11 bytes of the header.
In our case the DWARF version should always be 2, but it may soon be common to find version 3. I think there may be some common thing between version 2 and 3, but I don't have checked it yet.
The abbrev offset will let you know where to find the corresponding entry in the .debug_abbrev table. Just add this offset to the base address of the abbrev section (you got it as we explain earlier, don't you ?)
Finally the pointer size will let you know the size of a pointer on the target architecture.
The most interesting information here is the abbrev offset, of course don't loose the others they will come handy later.
The least significant information here is probably the DWARF version, but when you know which version you are currently using that may make a good error check.
You should now have the address where you have to read for the abbrev of the current CU:
mapped_binary_base + .debug_abbrev_offset + CU_abbrev_offset
After this header you will find the CU entry, found on the CU by itself.
The Index is written in LEB128 format, unsigned, aka ULEB128. To get more information you should refer to the Data Types paragraph.
This index will allow you to find the right part in the .debug_abbrev corresponding CU entry.
Let's have a look at the abbrev section:
Each CU entry in the abbrev section will look the way it's shown on the right of Fig-2
The first thing you should read in both section, info and abbrev, is the index, here in ULEB128 too.
If those two index (in .debug_info and .debug_abbrev) don't correspond there is a big chance that you made a mistake while reading previous information.
Note: That won't happen in the later explanations as I read abbrev and find the corresponding entry by searching by index.
Then comes another ULEB128, the Tag, this will tell what will be representing the coming information in this entry, they correspond to the DW_TAG_* that you can find in the official documentation or in the headers files with thoses defines.
Then comes a one byte flag telling you wheter it will have child or not.
In DWARF 2, information create a tree, but as it is in binary format, you'll have to represent yourself this tree, the only information is that child flag telling you wheter it's a leaf or not of the tree.
The tree organisation may be somthing like that:
-function
|--> type
|--> parameter
|-----> type
|--> parameter
|-----> type
The first entry will tell you that from now on will have a function information, with the Child flag set to 1.
The second will have the Child flag set to 0, and will be the return type of the function.
The third will have the Child flag set to 1 and will give you the parameter name.
The fourth will have the Child flag set to 0 and will give the type of the parameter.
And so on...
In fact things that are part of a tree always refer to their parents.
After this flag will always be a pair of ULEB128: Attr and Form.
The first one, Attr will give you information about what you are about to read, the name, the value, and lots more possibilities. They are the DW_AT_* in the DWARF 2 defines.
The second one will be telling the FORM, that will be usefull to be able to know how long your next read in the current CU will be. They of course are the DW_FORM_* in the DWARF 2 defines.
The end of a section will be a pair of ULEB128 both set to 0.
That's it for the explanations of the organization, the best thing to do is probably to play around and code some program that will read those information.
Let's try to have a look at how I was reading DWARF 2 information in my program.
First I was getting the .debug_* section from the mapped binary, .debug_info first, getting the offset, the size and setting a pointer to the beginning, the one that will move in this section. Next the same thing was done for .debug_abbrev, and the same for .debug_str if available (most binary will have one if it was compiled with more than one file, that is used to prevent storage of redundant information).
From here everything will be done in loop, while we are done.
If I recall well, to know if I was done I was checking that my moving pointer was in bounds (between base and base + size of the .debug_info section), and that my current deepness wasn't 0.
I was counting how deep I was in the tree using the child flag, when you find the flag set to 1 you increase the deepness in the tree. Decreasing is a bit more disapointing, you need to find an index that is 0, the child flag set to 0 only indicate that you are reading a leaf. They may be several leaf following each other.. As far as I've understand the official documentation that doesn't seem quite clear, but that's the way I've done it and it was working well.
The first step of the loop is to read the CU header getting the important information and store them if needed. I was storing everything with a lots of linked list, that may be somewhat overkill but it probably depends on what you plan to do with thoses information. That's up to you.
You now have the abbrev offset for the corresponding CU.
From this offset I then read all the entry of this abbrev section, and store all information in a linked list: index, tag, child flag, and a linked list of attr/form pair.
Then, read a ULEB128 from the .debug_info section to find the index of the current entry.
Now I have a function that find the right abbrev entry from the index stored in the previous step.
Next step is to have a look at the TAG and the Child flag to find out what we are going to read in .debug_info, and where we are in the tree.
Now while we don't find a couple attr/form set to 0/0 we keep on reading.
The form part telling how long we will have to read at the current position in info. For more information about this refer to the data types section of this document.
The attr will tell what is the part you are going to read, that mostly tell you if your program need this information and let you choose what you will want to do with it. This part is dependent of your needs, but what you must really do well here, is move your pointer to the right position depending of the form you've read. As I've already told, any mistake here will be hard to find out until you get really used to this kind of mistake and know the binary you're testing like the palm of your hand.
When you find the pair 0/0 that is to say the current entry for this CU is finished, restart reading index and so on until you find a 0 index.
At this point you've successfully read a complete CU, you can now loop and restart reading from CU header, and CU data
3. Data types
Let's start getting familliar with the different types of data that are used in DWARF 2.
All types are refered to, using their defines as they are found in the official documentation. You may also found most of the defines in the header I used in my project.
Note: I may have lighten this header by removing unused sections, if you seem to miss something have a look at the headers of the libdwarf.
Here are the main types you will find in DWARF 2:
- LEBs
Either LEB128 or ULEB128 (signed, unsigned respectively), are undefined length data. They are used pretty often in DWARF 2. You have to decode them to get their length and their value. The official documentation have some pseudo code on how to decode LEBs, I've copied this pseudo code to Appendix
Most of the time they are used in other types rather than directly.
- References:
DW_FORM_/ref1/ref2/ref4/ref8/ref_udata
There are lots of references in DWARF 2 format. They are pretty useful to avoid redundant information. This type is referencing an offset from the beginning of the current CU.
Their names let you know which size they are in the CU (in bytes).
For exemple when you find a DW_FORM_ref2 in the abbrev section, you know that the value to be read in the current CU is 2 bytes long.
DW_FORM_ref_udata is a ULEB128.
- Blocks:
DW_FORM_blockX
X may be 1 2 4 8 or inexistant, once again this will let you know the length to be read in the current CU. If it is only a DW_FORM_block it is a ULEB128.
What will be read at this point will be a size, this size will tell you how many bytes you have to read after this entry, that's the "block" of data.
For exemple let's say you found a DW_FORM_block1, you read one byte at the current position in the info section. If you read 0x0A there is 10 bytes of data following 0A, the next entry for this CU will be 10 bytes after the current position.
- Datas:
DW_FORM_dataX
Those are just uninterpreted data, on the length corresponding to the name
1/2/4/8 are for the size in bytes.
udata and sdata are for ULEB128 and LEB128 respectively.
- Flag:
Simple flag on one byte.
- Addr:
An address, coded on the size of a pointer on the target architecture, you should have found this size in the CU Header.
- String and strp:
They are both null terminated strings.
DW_FORM_string are directly found in the info section, at the current position.
DW_FORM_strp are 4 bytes coded offsets telling where to find the string in the .debug_str section.
That's all I plan to explain on this document, mainly because I haven't coded the other parts. This section will be a little overview of what and how you should probably get the other information.
You can for example get the line number and the function adresses.
The DWARF 2 use it's own pseudo calling convention, so in fact you will have to decode the execution of the program using this system.
Let's say you know in which file you are, and at which program counter you start. You should have found both by reading the beginning information, after this you have to see how the program will run in this calling convention.
Each step you'll do you should find of how many lines you have progress, and the same goes for the position of the PC.
Unfortunately I don't remember the how this is done, and I don't have enough motivation for searching about it, maybe in a future update of this document, or in the next part... I would like to be able to complete this document with a second part about the other information that I you can get using DWARF 2.
I'll se if I have time, motivation and if anybody read this firt part and ask for the second :)
This is only a copy/paste of the pseudo code given in the official documentation, it's up to you how you implement those.
Keep in mind you'll need to read the value and know the length read to go keep reading at the rigth place.
Decode unsigned LEB128 number:
result = 0;
shift = 0;
while(true)
{
byte = next byte in input;
result |= (low order 7 bits of byte << shift);
if (high order bit of byte == 0)
break;
shift += 7;
}
Decode signed LEB128 number:
result = 0;
shift = 0;
size = no. of bits in signed integer;
while(true)
{
byte = next byte in input;
result |= (low order 7 bits of byte << shift);
shift += 7;
/* sign bit of byte is 2nd high order bit (0x40) */
if (high order bit of byte == 0)
break;
}
if ((shift < size) && (sign bit of byte is set))
/* sign extend */
result |= - (1 << shift);
--- EOF ---
Here come the end of my first real article, trying to explain something useful, sorry for all the english errors I may have left, and forgive me if it's not clear enough... At least I tried :p
| | -- 39 comments -- |
| Comments | | tups -- Friday 04th of August 2006 20:54:44 PM | |
| really nice article which probably be very usefull for me soon. thanks dude and gogo for the second part :p | | --- |
| -- Friday 22nd of September 2006 07:29:06 AM | |
Hi ,
This is a very nice article what i was looking for. I want to reconstrunct all structure information from unix ELF file. could you help me with your experience.If you could give some kind of examples programs or some tips to do that , it will be a timely help to me.
Merci Beacoup!
Poornima | | --- |
| bleader -- Friday 22nd of September 2006 12:39:06 PM | |
I'm not sure of what you need. When I read your what you ask I mainly feel it's like what I've explained in this article :)
I added this file with the datas structures I used to store informations, that may guide you, of course it probably won't be useful itself, but that may lead you on what you want to store and how.
If you need to contact me mail me using bleader@ this domain.
De rien. | | --- |
| -- Tuesday 26th of September 2006 11:27:39 AM | |
Hi bleader,
I have sent you an Email could you please have a look.
Merci
Poornima | | --- |
| bleader -- Tuesday 26th of September 2006 11:28:33 AM | |
I've edited you post to avoid getting spam (since this message I already got 5 spams :)
I'm making a mail to answer your mail :) | | --- |
| -- Monday 16th of October 2006 12:46:23 PM | |
Hi bleader,
Its a great article, just what i was lookin for , Im trying to gather debug info of local variables. Cud you help me on this.
regards,
melvin
| | --- |
| bleader -- Sunday 22nd of October 2006 09:58:52 AM | |
oups sorry, seems my rss feed for comments sucks, I just seen your comment.
Yes I can try to help you out on this, if it's not too late :)
| | --- |
| -- Thursday 18th of January 2007 11:21:28 AM | |
| hello, please tell me how to get to the start of .debug_info present in object file...Is the .debug_info is in binary form.whenever I open object file using text editor junk characters will appear.is it possible to access bits just by including object file using fopen() function... | | --- |
| bleader -- Friday 19th of January 2007 17:46:21 PM | |
Yes the .debug_info is in binary form in the binary, I supposed it's in objects files too, but I never used it myself on objects.
You probably won't be able to get the sections you need by using fopen(). fopen will simply let you read the data in the binary, ELF binary are using offsets to let you know where to get each section, that's why most of the time binary are mapped to memory.
I suggest you to either to use something like libelf or getting to know the ELF format a bit before searching how to use DWARF informations you'll definitly need it.
To try to give you some directions you have to map binary file in memory, read the structure of the ELF header, get the section header table. Using this table you should be able to find the .debug_info section. Of course if you only want to acces this section you can run readelf on you object file, find the offset and read there with an hexadecimal editor.
Hope that will give you a start | | --- |
| -- Tuesday 30th of January 2007 19:05:24 PM | |
hi bleader,
this article helped me know about dwarf 2...
1)But I am not able to find the exact location of .debug_info in the a.out file.
What is the location of the .debug_info in the exe file.
Whenever i open a.out file. it starts with ELF followed by some junk characters... I am not able to find the Header of the .debug_info in the binary file.
2)Does Linux version supports DWARF 2 format.?
--Thank you............ | | --- |
| bleader -- Monday 05th of February 2007 00:39:34 AM | |
Hi.
1) The .debug_info is not at a fixed placed, it will vary depending on your file, the fastest way to find the offset where this section begin is to use:
readelf -e a.out
This will give you lot of information, and a line looking like this:
[27] .debug_info PROGBITS 00000000 000cb0 000764 00 0 0 1
The 000Cb0 is the offset of the section .debug_info in the binary I used.
2) On most linux distributions, gcc compile with DWARF2 debug information by default, of course remember you have to compile you file with the '-g' option. On some versions of BSD you may still find gcc compiling with stabs instead of dwarf, in this case you should add the compilation option '-gdwarf-2' to enable the DWARF 2 debugging information format.
Sorry for answer so late, I'll try to watch the comments more often :) | | --- |
| -- Tuesday 06th of February 2007 08:17:14 AM | |
1) How to use Offset address of .debug_info provided by the readelf command. Is it the actual physical address or the relative address from the start of .a.out file?
2) How to do Memory Mapping in Linux.
3) Is it necessary to store the contents of the exe file into into a buffer first?
Please help......
Regards-----
Jennifer | | --- |
| bleader -- Thursday 08th of February 2007 20:49:28 PM | |
1) If you're opening the a.out file with an editor, it's probably the address from the start yes, otherwise once mapped to memory it will be the address of the mapped binary + this offset
2) Use the mmap function:
- use stat() to retrieve size of the file (file_size)
- open the file with open() to get the file descripton (fd)
- call mmap something like that:
mapped_file = mmap(NULL, file_size, PROT_READ, fd);
with mapped_file being a void * pointing to the start of the mapped file.
3) That's what mmap will do, not really loading all the file at once if the memory consumption is your worry. But as most of the information have to be accessed in parallel in .debug_info and .abbrev_info, it's most likely that you will need to have a large part of the file in memory
Hope it helps :) | | --- |
| -- Thursday 15th of February 2007 09:47:51 AM | |
How To Get prefix form information stored in the .debug_info?
Is it necessary to form a tree like structure to get the information from the .debug_info....?
please Help....
Thank u..... | | --- |
| bleader -- Friday 16th of February 2007 14:45:03 PM | |
I don't really get what you mean by prefix, the only thing to do is to read both .debug_info and .debug abbrev at the same time to know what you are reading, and proceed accordingly to your needs.
It's not necessary to form a tree yourself, it depends on what you want to do, but you have to keep in mind that the information ARE in a tree. You'll an entry defining a structure, the next entry will be the first member of this structure and so on. | | --- |
| -- Friday 16th of February 2007 18:02:37 PM | |
hello bleader,
i tried using the --dwarf -dump cmd in my system for reading the table info..but no results were displayed...should i install this feature as aspecial package to my gcc
plz help..
thanks in advance
| | --- |
| bleader -- Saturday 17th of February 2007 12:38:53 PM | |
to which program do you pass this option ?
gcc handle the -gdwarf2 to uses dwarf2 symbols, at first I don't recall any program having --dwarf-dump option.
gcc won't dump the infos as far as I know | | --- |
| -- Sunday 18th of February 2007 05:53:22 AM | |
what i actually meant to do was that i tried to print the dwarf2 information for .o file compiled in gcc.
the exact command which i used is
dwarfdump "name of .o file"
i read in a linux help manual,that this command will print the tags,attributes and their associated forms for the abbrev units in the .o file.
but the i didnot get these expected results...
| | --- |
| bleader -- Sunday 18th of February 2007 12:07:20 PM | |
Ah ok, sorry :)
I don't recall how it works I'm not even sure I was able te compile it when I was working on DWARF2. If I recall correctly I mostly read the sources as a guide to understand as it won't compile and I didn't bother seaching for a way to make it work, or something like this.
Sorry I won't be able to help you on this | | --- |
| -- Sunday 18th of February 2007 15:59:49 PM | |
| hey thats ok.thanks a lot for replying. | | --- |
| bleader -- Sunday 18th of February 2007 21:26:41 PM | |
I've taken some time to compile the libdwarf and dwarfdump
Did you tried to add option to dwarfdump ? With -a on an object file I get everything listed.
-b for abbrev and -i for info seems to be working too. Hope that may help you (if you ever come back to read this as I didn't had an answer earlier)
| | --- |
| -- Monday 19th of February 2007 16:23:48 PM | |
hi bleader,
can you help me in getting inheritance related information from the source code(c++) using DWARF format information of a .o file compiled using gcc.any sample codes will be very useful.
thanks in advance. | | --- |
| -- Monday 19th of February 2007 18:00:03 PM | |
Hi bleader,
I was reading the .debug_abbrev and .debug_info,
After reading the .debug_abbrev tables, Although I got the
some tags,variables,... But i am not able to relate them...
Can u help me how to read the rest of .debug_info and then
relate them under a common tree structure......
Thank you... | | --- |
| bleader -- Wednesday 21st of February 2007 01:17:41 AM | |
About C++, I'm sorry but haven't looked at the inheritance, what I did was basically dumping dwarf information, I know it was working on C++ files but didn't looked further (as the dump was pretty big due to the std). If I get some time, I'll try to have a look at it, but I cannot promise you anything :)
About the tree structure I think you're the one I've just mailed about it, I'll copy/paste the mail here anyway as this may me useful to someone else too :)
For the tree part, each entry you will read have a DW_CHILDREN_yes/no
(in the abbrev section) telling you if that entry will have children or
not. If it have children, then the following entry will be child of this
entry until you read an entry with a 0 index (I don't recall if you'll
find the 0 index in abbrev or info, or both, sorry about that)
I'll try to have a little example: (index : child)
1 : yes
|-> 2 : no
|-> 3 : yes
| |-> 4 : no
| |-> 5 : no
| |-> 0
|-> 6 : no
|-> 0
7 : no
That's how you can generate a tree and find out relatives information, I
hope that's clear enough it's not easy to explain :)
| | --- |
| -- Thursday 22nd of February 2007 05:55:43 AM | |
hello bleader,
i had asked you some help on sample codes for exploring inheritance in c++,it would be great help if u can give some code snippets for say,listing members in a class or listing members of the base class of a derived class.your previous reply was that you might work,well it would be agreat help if u can give these sample codes.
thanks in advance | | --- |
| -- Sunday 25th of February 2007 12:35:45 PM | |
hi,
how to get the section headers( spcfc .debug_info) from ELF files?
Right now i m using readelf -S command to get the section header addresses but i want to get that from C prgm.
Can u plz help us??? | | --- |
| bleader -- Monday 26th of February 2007 12:16:10 PM | |
Sorry for the inheritance I didn't had time to search this, but the tree principle I explained in my previous post is probably a good start as it is probably showed as a children entry in the tree.
To get the .debug_info in a C program, the explanation is already in the comment of the 8th february. You need to mmap the file, read the elf header, get the section header where you will get each section offset, and then go to the right offset. | | --- |
| -- Monday 26th of February 2007 14:30:18 PM | |
yes,i read the tree principle that was in the post.But if at all you find the time to write some small sample codes for extracting the information i told about earlier(listing members of base class or derived classs in the inheritance hierarchy),please mail it to the following id:
thanks and regards. | | --- |
| bleader -- Monday 26th of February 2007 14:29:48 PM | |
Ok, i'll do it.
I've remove your mail from the previous post to avoid you getting too much spam (even if gmail spam filter is really good :), but I have in in my mailer agent. | | --- |
| geek.be -- Thursday 01st of March 2007 06:22:09 AM | |
hello bleader,
i was the guy who asked you for some sample codes.i hope you will send it atleast before this weekend..please...
also please attach a .o file along with it.
thank you ...
eagerly awaiting your reply | | --- |
| -- Saturday 03rd of March 2007 18:12:13 PM | |
Hi ,
1)
Where will be the Caller/Callee information in the Dwarf-2 debug information...?
2)How to fetch that information...?
3)Is there any other location in ELF file, that is used to store the caller and callee information....?
--Thank you...
| | --- |
| -- Saturday 03rd of March 2007 18:17:46 PM | |
Hi...
I am having a problem in reading the structure/class related information from .debug_info/.debug_abbrev...
example..
Let
struct ABC
{
int int_var;
float float_var;
}struct_var;
be the structure...Then i am not getting the data type of the struct_var (struct ABC) correctly..
Could u please help......
Thank you..... | | --- |
| bleader -- Sunday 04th of March 2007 16:35:11 PM | |
About the callee/caller information:
------------------------------------
This information is not in DWARF2 as far as I know. Dwarf is a debug information format, it only store information about variables names and type, function names and parameters and so on. The information you seek only have a meaning at runtime, and therefore are not in dwarf, you may be able to get this information by tracing the process exectution via ptrace, but this is totally out of the scope of this article, hope that gives you a little useful advice.
About the struct:
-----------------
what you should have is something like that, not specifically in this order but that will help getting the idea
offset 0x10: DW_TAG_base_type int
offset 0x42: DW_TAG_base_type float
offset 0x78: DW_TAG_structure_type ABC
child: DW_TAG_variable name: int_var type reference to 0x10
child: DW_TAG_variable name: float_var type: ref to 0x42
offset 0x99: DW_TAG_variable name struct_var type: ref to 0x78
| | --- |
| sharanyaa -- Saturday 10th of March 2007 15:40:26 PM | |
hi,
do you know what are the changes reqiured to convert a program which works fine for ELF32 format to ELF 64 bit format,
if otherwise, do you know any other sources of information like forums or weblinks....
please i am running close one a deadline
| | --- |
| bleader -- Monday 26th of March 2007 10:13:01 AM | |
Disregard the previous version of this post I had misread your post...
It's mostly changing the elf structures you use to make them 64bits versions and that should do most of the work. | | --- |
| manju -- Friday 01st of June 2007 00:09:30 AM | |
Hi Bleader,
i'm facing problem when trying to bring up an application.
The Stack trace points to an Corrupted DWARF expression.
Below is stack trace for your reference.
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x005177a5 in raise () from /lib/tls/libc.so.6
#2 0x00519209 in abort () from /lib/tls/libc.so.6
#3 0x0095114b in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6
#4 0x0094ee61 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.6
#5 0x0094ee96 in std::terminate () from /usr/lib/libstdc++.so.6
#6 0x0094efdf in __cxa_throw () from /usr/lib/libstdc++.so.6
#7 0x008f1cdb in std::__throw_logic_error () from /usr/lib/libstdc++.so.6
#8 0x00931dd4 in std::basic_string, std::allocator >::basic_string$base ()
from /usr/lib/libstdc++.so.6
#9 0x00931e92 in std::basic_string, std::allocator >::basic_string ()
from /usr/lib/libstdc++.so.6
#10 0xf68cc011 in CWFTransaction053::CWFTransaction053 ()
at /vobs/aix_dev/tvapps/Cashbox/cashbox/src/nondollar/include/CWFCTRMainInfo.h:431
#11 0xf7fe74ab in getTransaction053FunctionPointer () at CWFAppInitialize.cc:2103
#12 0xf6603fa7 in CWFTransactionManager::newTransactionInstance (this=0x83270f8, type_=TXN053)
at CWFTransactionManager.cc:205
#13 0xf6603e41 in CWFTransactionManager::createTransaction (this=dwarf2_read_address: Corrupted DWARF expression.
) at CWFTransactionManager.cc:170
#14 0xf687108b in CWFTransactionScreen053::doCreateTransaction (this=0x820ef38) at CWFTransactionScreen053.cc:332
#15 0xf660b002 in CWFTransactionScreen::initialize (this=0x820ef38) at CWFTransactionScreen.cc:379
#16 0xf65827e4 in CWFGUIManager::createTransactionScreen (this=0x828f278, type_=TXN053) at CWFGUIManager.cc:914
#17 0xf608abf0 in CWFMainWindowScreen::handleMenuItemClick (w=0x82800e0, client_data=0x81f0d90, xt_call_data=0xffffabb0)
at CWFMainWindowScreen.cc:898
#18 0x006308f7 in XtCallCallbackList () from /usr/X11R6/lib/libXt.so.6
#19 0x009e4cb0 in _XmCascadingPopup () from /usr/X11R6/lib/libXm.so.3
#20 0x009e4f12 in _XmCascadingPopup () from /usr/X11R6/lib/libXm.so.3
#21 0x00ada63d in _XmAllowAcceleratedInsensitiveUnmanagedMenuItems () from /usr/X11R6/lib/libXm.so.3
#22 0x00ada9ba in _XmRC_KeyboardInputHandler () from /usr/X11R6/lib/libXm.so.3
#23 0x0063e45f in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6
#24 0x0063ee8a in _XtOnGrabList () from /usr/X11R6/lib/libXt.so.6
#25 0x0063f0c9 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6
#26 0xf65857cf in CWFGUIManager::eventLoop (this=0x828f278, eventLoopComplete_=@0xf675401c) at CWFGUIManager.cc:2263
#27 0xf6585190 in CWFGUIManager::ActivateMainEventLoop () at CWFGUIManager.cc:2086
#28 0xf7fe9eb1 in CWFAppInitialize::start (this=0x8298be0) at CWFAppInitialize.cc:3968
#29 0xf7ff1312 in cashbox_main (argc=3, argv=0xffffb524) at mainprogram.cc:225
#30 0x08048c04 in main (argc=3, argv=0xffffb524) at cashbox.cc:7
Can you provide me pointers, which can help me to resolve this issue?
thanks,
| | --- |
| bleader -- Wednesday 20th of June 2007 14:54:36 PM | |
Sorry for taking so long to answer.
A callstack of a program I don't know isn't really helping me understand anything about your problem, DWARF informations are dynamic, and I really don't have a clue what this is doing.
Actually If you want to contact me again, you'll have to use mail, I'll deactivate comments (spam). | | --- |
| Rick -- Wednesday 28th of January 2009 16:13:29 PM | |
Hey, thanks a lot for your article. Two questions:
1) Do you know how could I obtain class member offsets for a given type?
and 2)
Is there a way to show the pages in a "printable format"? I had to edit the CSS by hand using Firefox Web Developer plugin. Otherwise the menu keeps popping on all printed pages.
Thanks! | | --- |
| sv -- Thursday 01st of April 2010 14:15:48 PM | |
Hi,
This is a useful doc. I am working on DWARF and want to extract informations like, source file names(CU), function names in a particular source file and for each function name the line numbers from start of function till end of function. I am able to get the source file name and function name from debug_info sections but i am not able to extract the line numbers information which is present in debug_line section. The issue is debug_line section gives the line numbers for a CU. I want for each function under CU. Is there a way to get thi. I apprecite you help. Can i mail to you regarding these issues? | | --- |
|