|
From: Madhan S. <mad...@gm...> - 2009-08-26 14:13:47
|
Hello, When intel compiler is used with profiler guided optimization, two new sections called "text.hot" and "text.unlikely" are created by the compiler. This is on Linux x86 32 bit. The symbols in these sections are not read by Valgrind and this causes many frames in memcheck error stack traces to be unresolved. Are there any ways to handle this. Thanks, Madhan. |
|
From: John R. <jr...@bi...> - 2009-08-26 14:42:02
|
> When intel compiler is used with profiler guided optimization,
> two new sections called "text.hot" and "text.unlikely" are
> created by the compiler. This is on Linux x86 32 bit.
Please show the relevant data from
readelf --sections foo.o
readelf --segments my_app
for an ET_REL object file foo.o that has text.hot and/or text.unlikely,
and for an ET_EXEC executable file my_app that is built from such objects.
--
|
|
From: Madhan S. <mad...@gm...> - 2009-08-27 05:10:20
|
Thanks for helping me John, here's the output
Sections from .o file:
There are 19 section headers, starting at offset 0x378b0:
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 000034 012162 00 AX 0
0 4
[ 2] .rel.text REL 00000000 0443d8 005f28 08 17
1 4
[ 3] .data PROGBITS 00000000 0121a0 0000c8 00 WA 0
0 32
[ 4] .rel.data REL 00000000 04a300 000048 08 17
3 4
[ 5] .bss NOBITS 00000000 012268 000000 00 WA 0
0 4
[ 6] .comment PROGBITS 00000000 012268 001fc4 00 0
0 1
[ 7] text.unlikely PROGBITS 00000000 01422c 01a8fc 00 AX 0
0 2
[ 8] .reltext.unlikely REL 00000000 04a348 0093a8 08 17
7 4
[ 9] .rodata PROGBITS 00000000 02eb40 0008ef 00 A 0
0 32
[10] .rel.rodata REL 00000000 0536f0 000e08 08 17
9 4
[11] text.hot PROGBITS 00000000 02f430 00005a 00 AX 0
0 2
[12] .reltext.hot REL 00000000 0544f8 000008 08 17
11 4
[13] .rodata.str1.4 PROGBITS 00000000 02f48c 0023ad 01 AMS 0
0 4
[14] .rodata.str1.32 PROGBITS 00000000 031840 005fd8 01 AMS 0
0 32
[15] .note.GNU-stack PROGBITS 00000000 037818 000000 00 0
0 1
[16] .shstrtab STRTAB 00000000 037818 000097 00 0
0 1
[17] .symtab SYMTAB 00000000 037ba8 006ac0 10 18
948 4
[18] .strtab STRTAB 00000000 03e668 005d6d 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)
Segments from executable:
Elf file type is EXEC (Executable file)
Entry point 0x84fd7d0
There are 8 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x00100 0x00100 R E 0x4
INTERP 0x000134 0x08048134 0x08048134 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
LOAD 0x000000 0x08048000 0x08048000 0x80d107c 0x80d107c R E
0x1000
LOAD 0x80d107c 0x1011a07c 0x1011a07c 0xe5544 0x116e1c RW 0x1000
DYNAMIC 0x80d10a8 0x1011a0a8 0x1011a0a8 0x00160 0x00160 RW 0x4
NOTE 0x000148 0x08048148 0x08048148 0x00020 0x00020 R 0x4
GNU_EH_FRAME 0x80d1004 0x10119004 0x10119004 0x0001c 0x0001c R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version
.gnu.version_
r .rel.dyn .rel.plt .init .plt .text text.unlikely text.hot .fini .rodata
.trace
.eh_frame_hdr .eh_frame
03 .ctors .dtors .jcr .dynamic .got .got.plt .data .data1 .bss
04 .dynamic
05 .note.ABI-tag
06 .eh_frame_hdr
07
Thanks,
Madhan.
On Wed, Aug 26, 2009 at 8:11 PM, John Reiser <jr...@bi...> wrote:
> > When intel compiler is used with profiler guided optimization,
> > two new sections called "text.hot" and "text.unlikely" are
> > created by the compiler. This is on Linux x86 32 bit.
>
> Please show the relevant data from
> readelf --sections foo.o
> readelf --segments my_app
> for an ET_REL object file foo.o that has text.hot and/or text.unlikely,
> and for an ET_EXEC executable file my_app that is built from such objects.
>
> --
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|
|
From: Tom H. <to...@co...> - 2009-08-27 07:47:35
|
On 26/08/09 15:13, Madhan Sadasivam wrote: > When intel compiler is used with profiler guided optimization, > two new sections called "text.hot" and "text.unlikely" are > created by the compiler. This is on Linux x86 32 bit. > > The symbols in these sections are not read by Valgrind > and this causes many frames in memcheck error stack traces > to be unresolved. > > Are there any ways to handle this. Probably not without changing valgrind, no. We could just add these sections to the ones we process, but I think we've probably gone as far as we can down that road and adding yet more will just make the ELF core even more unreadable that it already is. We really need to rewrite things in a scalable way where we can track an arbitrary number of text and data sections. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Madhan S. <mad...@gm...> - 2009-08-31 08:45:13
|
Thanks Tom, One of the options is to fuse the new sections into one big ".text". gcc-help suggested using ld's linker script to achieve this. This does help with the function names in stack traces. Do you see any trouble with this (other than a performance hit) ? Is a similar treatment required for .data and .data1 sections ? Thanks again, Madhan. On Thu, Aug 27, 2009 at 1:17 PM, Tom Hughes<to...@co...> wrote: > On 26/08/09 15:13, Madhan Sadasivam wrote: > >> When intel compiler is used with profiler guided optimization, >> two new sections called "text.hot" and "text.unlikely" are >> created by the compiler. This is on Linux x86 32 bit. >> >> The symbols in these sections are not read by Valgrind >> and this causes many frames in memcheck error stack traces >> to be unresolved. >> >> Are there any ways to handle this. > > Probably not without changing valgrind, no. > > We could just add these sections to the ones we process, but I think we've > probably gone as far as we can down that road and adding yet more will just > make the ELF core even more unreadable that it already is. We really need to > rewrite things in a scalable way where we can track an arbitrary number of > text and data sections. > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > |