Re: [libunwind] Some basic questions about libunwind

[Archie Cobbs]

David Mosberger wrote:
>   Archie> Of course it's still necessary to crawl the stack for
>   Archie> constructing exception stack traces (JC knows how to map PC
>   Archie> addresses to original Java method and source code line
>   Archie> numbers).
> 
> Yes, but for that, there are more APIs.  For example, glibc provides
> backtrace() and GCC 3.x provides _Unwind_Backtrace().
> 
> Again, I don't mind at all if libunwind is the answer, but I wanted to
> point out potential alternatives that I'm aware of.

You are correct.. since I already know how to crawl the
stack from function to function, and assuming we did a
conservative scan for references, then libunwind doesn't
add anything to this particular task.

>   Archie> I'm already loading and relocating all the sections myself,
> 
> Why is this better than just dlopen()()ing a shared object?

My objects are not shared objects, they are relocatable objects,
which are more efficient (PIC code is not required). Of course,
this means if two classloaders load the same class then I have
to load the file twice, but that is rare.

Also, some O/S's have problems if you try to mmap() thousands
of files at once, which would be the case if i did that.

In addition, I save memory because my loader does not need to
page-align each file as dlopen() does. I don't lose on average
1/2 page of memory per file.

In short, there are disadvantages to using dlopen() with thousands
of small files that are avoided by using my own loader.

Another reason is I need to scan the file's symbol table. From it
I infer the existence of contained classes and methods (multiple
objects can be linked together, causing all the classes to be
loaded simultaneously).

>   Archie> so ideally what I'd prefer to do is just say "Here
>   Archie> libunwind, this is the .debug_foo section"... i.e., if
>   Archie> libunwind already knows how to parse DWARF2 then it would be
>   Archie> nice to reuse that capability. Would that require new
>   Archie> libunwind API functions?
> 
> No, you can do that via _U_dyn_register().  Assuming your objects have
> a binary search-table (they should), you'd just have to fill in a
> unw_dyn_info_t structure, with "format" set to UNW_INFO_FORMAT_TABLE
> and fill in the other info (such table-length and the starting/ending
> instruction-pointer covered by the table).  All the DWARF2 parsing
> will be done by libunwind.

I think a binary search table is only present in shared objects, right?
Since my objects are just plain old relocatable objects then I don't
think they have that. For example:

$ file /usr/local/jc/obj/java/lang/Object.o
jc/obj/java/lang/Object.o: ELF 32-bit LSB relocatable, Intel 80386,
version 1 (SYSV), not stripped
$ readelf -S /usr/local/jc/obj/java/lang/Object.o
There are 28 section headers, starting at offset 0xbcbc:

Section Headers:
   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf 
Al
   [ 0]                   NULL            00000000 000000 000000 00      0   0  0
   [ 1] .text             PROGBITS        00000000 000040 0006b2 00  AX  0   0 
16
   [ 2] .rel.text         REL             00000000 00dd10 000260 08     26   1  
4
   [ 3] .data             PROGBITS        00000000 000700 000604 00  WA  0   0 
32
   [ 4] .rel.data         REL             00000000 00df70 0002e8 08     26   3  
4
   [ 5] .bss              NOBITS          00000000 000d04 000000 00  WA  0   0  
4
   [ 6] .debug_abbrev     PROGBITS        00000000 000d04 0002e2 00      0   0  
1
   [ 7] .debug_info       PROGBITS        00000000 000fe6 005747 00      0   0  
1
   [ 8] .rel.debug_info   REL             00000000 00e258 0028d8 08     26   7  
4
   [ 9] .debug_line       PROGBITS        00000000 00672d 00031a 00      0   0  
1
   [10] .rel.debug_line   REL             00000000 010b30 000008 08     26   9  
4
   [11] .rodata           PROGBITS        00000000 006a60 000428 00   A  0   0 
32
   [12] .rel.rodata       REL             00000000 010b38 0001e0 08     26   b  
4
   [13] .rodata.str1.1    PROGBITS        00000000 006e88 0001e7 01 AMS  0   0  
1
   [14] .rodata.str1.32   PROGBITS        00000000 007080 0000df 01 AMS  0   0 
32
   [15] .debug_frame      PROGBITS        00000000 007160 000164 00      0   0  
4
   [16] .rel.debug_frame  REL             00000000 010d18 0000c0 08     26   f  
4
   [17] .debug_pubnames   PROGBITS        00000000 0072c4 0005b2 00      0   0  
1
   [18] .rel.debug_pubnam REL             00000000 010dd8 000008 08     26  11  
4
   [19] .debug_aranges    PROGBITS        00000000 007876 000020 00      0   0  
1
   [20] .rel.debug_arange REL             00000000 010de0 000010 08     26  13  
4
   [21] .debug_ranges     PROGBITS        00000000 007896 000288 00      0   0  
1
   [22] .debug_str        PROGBITS        00000000 007b1e 004080 01  MS  0   0  
1
   [23] .note.GNU-stack   PROGBITS        00000000 00bb9e 000000 00      0   0  
1
   [24] .comment          PROGBITS        00000000 00bb9e 000026 00      0   0  
1
   [25] .shstrtab         STRTAB          00000000 00bbc4 0000f7 00      0   0  
1
   [26] .symtab           SYMTAB          00000000 00c11c 0008a0 10     27  4d  
4
   [27] .strtab           STRTAB          00000000 00c9bc 001353 00      0   0  
1
Key to Flags:
   W (write), A (alloc), X (execute), M (merge), S (strings)
   I (info), L (link order), G (group), x (unknown)
   O (extra OS processing required) o (OS specific), p (processor specific)

Cheers,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com


*
Confidentiality Notice: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and may contain confidential and 
privileged information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies of 
the original message.
*