[Bug binutils/2768] readelf and segmented addresses in DWARF2/3 aranges
--- Additional Comments From stephane dot chauveau at philips dot com 2006-06-15 07:41 --- I am currently trying to implement DWARF2 support for our architectures so I can only provide samples that show my current interpretation of the specs. More precisely, our architectures are not exactly segmented - at least not like the x86 was. They are DSPs in which the PROGRAM memory is distinct from the DATA memory. Some models also support two distinct DATA memories (typically named X and Y) and a shared version (XY). To make things even more complex, parts of the PROGRAM and DATA memories can be paged (i.e multiple versions selectable via a control registers). The addresses themselves are 16bit or 32bit. In DWARF1, we used to encode th memory and page information in the unused bits of the 32bit addresses. In DWARF2, we want to encode those information in the segment fields (e.g AT_segment and AT_address_class). I will provide samples for an architecture with the following characteristics: - an address is 32bit in which only 24bit are currently used. - two memories PROGRAM & DATA encoded as segment numbers 0 and 1. -- http://sourceware.org/bugzilla/show_bug.cgi?id=2768 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/2768] readelf and segmented addresses in DWARF2/3 aranges
--- Additional Comments From stephane dot chauveau at philips dot com 2006-06-15 07:46 --- Created an attachment (id=1091) --> (http://sourceware.org/bugzilla/attachment.cgi?id=1091&action=view) reference elf file (not segmented) in that version, the arange section is not explictly segmented. The 'segment' is implicitly encoded in the most significant 8 bit of each 32bit address. So, for example, 010b describes a range at address 0x0b in segment 0x01 (DATA). # readelf --debug-dump=aranges a_4_0.elf The section .debug_aranges contains: Length: 52 Version: 2 Offset into .debug_info: 0 Pointer Size: 4 Segment Size: 0 Address Length 010b 2 0105 9 0200 20 0214 536 -- http://sourceware.org/bugzilla/show_bug.cgi?id=2768 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/2768] readelf and segmented addresses in DWARF2/3 aranges
--- Additional Comments From stephane dot chauveau at philips dot com 2006-06-15 07:53 --- Created an attachment (id=1092) --> (http://sourceware.org/bugzilla/attachment.cgi?id=1092&action=view) elf file with address_size=3 bytes and segmen_sizet=1byte In that version, I indicate explicitly that an address is compose of a 3 bytes offset and a 1 byte segment so still a total of 4 bytes. Readelf does not like it at all: # readelf a_3_1.elf The section .debug_aranges contains: Length: 52 Version: 2 Offset into .debug_info: 0 Pointer Size: 3 Segment Size: 1 Address Length readelf: Error: Unhandled data length: 3 Aborted -- http://sourceware.org/bugzilla/show_bug.cgi?id=2768 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/2768] readelf and segmented addresses in DWARF2/3 aranges
--- Additional Comments From stephane dot chauveau at philips dot com 2006-06-15 08:04 --- Created an attachment (id=1093) --> (http://sourceware.org/bugzilla/attachment.cgi?id=1093&action=view) elf file with address_size=4 and segment_size=4 In the two previous samples, I rely on the fact that only 24 of the 32 bits are addressable. This is a limitation of the current implementation and not an intrinsic property of the architecture itself. In this sample ELF file, the segmented address is encoded in 8 bytes: 4 for the address itself and 4 for the segment. Readelf does not fail on that one but misinterpret the number of ranges: # readelf --debug-dump=aranges a_4_4.elf The section .debug_aranges contains: Length: 84 Version: 2 Offset into .debug_info: 0 Pointer Size: 4 Segment Size: 4 Address Length 000b 1 0002 1 0005 1 0009 1 0200 0 0014 0 0214 0 0218 0 -- http://sourceware.org/bugzilla/show_bug.cgi?id=2768 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/2768] readelf and segmented addresses in DWARF2/3 aranges
--- Additional Comments From stephane dot chauveau at philips dot com 2006-06-15 08:24 --- (From update of attachment 1093) The ELF file is incorrect (the end marker in a .debug_arange section is 2*4bytes instead of 2*8bytes) -- What|Removed |Added Attachment #1093 is|0 |1 obsolete|| http://sourceware.org/bugzilla/show_bug.cgi?id=2768 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/2768] readelf and segmented addresses in DWARF2/3 aranges
--- Additional Comments From stephane dot chauveau at philips dot com 2006-06-15 08:33 --- Created an attachment (id=1094) --> (http://sourceware.org/bugzilla/attachment.cgi?id=1094&action=view) Proper version of a_4_4.elf A proper version of the previous sample a_4_4.elf. Readelf does not crash but interpret each offset&segment as a pair address&length. # readelf --debug-dump=aranges a_4_4.elf The section .debug_aranges contains: Length: 92 Version: 2 Offset into .debug_info: 0 Pointer Size: 4 Segment Size: 4 Address Length 000b 1 0002 1 0005 1 0009 1 0200 0 0014 0 0214 0 0218 0 -- http://sourceware.org/bugzilla/show_bug.cgi?id=2768 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/2768] readelf and segmented addresses in DWARF2/3 aranges
--- Additional Comments From stephane dot chauveau at philips dot com 2006-06-15 09:21 --- A few more remarks: (1) Because of the alignment constraints, it is probably safe to assume that the total size of each address (including the segment) will be a power of two. Readelf should be safe if it covers the total address sizes of 2, 4 & 8. The case address_size=2 and segment_size=2 is a likely to happen since DSPs with 16bit addresses and complex memory features (paging, PROG/DATA, ...) are quite common. I do not have any samples yet. (2) The DWARF specs do not specify how the segments is encoded in the address so readelf should simply dump the overall value. (3) The cases such as address_size=4 & segment_size=4 are problematic when readelf is built without 64bit support. The functions get_byte_little_endian() and get_byte_big_endian() are only providing 4 of the required 8 bytes. Displaying only part of the values is a minor issue. What is more problematic is that the detection of the end marker (2 times ZERO) could be incorrect. A simple way to have a very generic implementation could be to process the address & length not using get_byte() but using two new functions: - one to dump an arbitrary sequence of bytes as a little or big endian hexadecimal number. - one to test if a sequence of bytes is only composed of zeros. -- http://sourceware.org/bugzilla/show_bug.cgi?id=2768 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gprof/2776] New: Strange profiling results
I've observed a strange results while profiling the following program:
$ cat test.c
#include
#define rdtscll(val) asm volatile("rdtsc" : "=A" (val))
struct timeval tv;
unsigned long long t;
void f (int n)
{
int x, y, z = 0;
for (x = 0; x < n; x++)
for (y = 0; y < n; y++) {
z += x * y;
rdtscll (t);
}
}
void g (int n)
{
int x, y, z = 0;
for (x = 0; x < n; x++)
for (y = 0; y < n; y++) {
z += x * y;
gettimeofday (&tv, 0);
}
}
int main (int argc, char *argv[])
{
int n;
for (n = 0; n < 200; n++) {
if (n % 2)
f (n);
else
g (n);
}
return 0;
}
My typical results are:
$ gcc -O2 -g -pg -o test test.c
$ /usr/bin/time ./test
0.13user 3.67system 0:03.80elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+107minor)pagefaults 0swaps
$ gprof test | head -n 10
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls ms/call ms/call name
95.85 0.40 0.40 100 4.03 4.03 f
4.79 0.42 0.02 100 0.20 0.20 g
% the percentage of the total running time of the
time program used by this function.
I.e. g() is much faster than f(). But this means that raw CPU insn (rdtsc) is
slower than kernel syscall wrapped by C library function (gettimeofday()), which
is just impossible. Let's split the program above and test f() and g()
separately:
$ cat test1.c
#define rdtscll(val) asm volatile("rdtsc" : "=A" (val))
unsigned long long t;
void f (int n)
{
int x, y, z = 0;
for (x = 0; x < n; x++)
for (y = 0; y < n; y++) {
z += x * y;
rdtscll (t);
}
}
int main (int argc, char *argv[])
{
int n;
for (n = 0; n < 200; n++)
f (n);
return 0;
}
$ gcc -O2 -g -pg -o test1 test1.c
$ /usr/bin/time ./test1
0.08user 0.00system 0:00.09elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+106minor)pagefaults 0swaps
$
$ cat test2.c
#include
struct timeval tv;
void g (int n)
{
int x, y, z = 0;
for (x = 0; x < n; x++)
for (y = 0; y < n; y++) {
z += x * y;
gettimeofday (&tv, 0);
}
}
int main (int argc, char *argv[])
{
int n;
for (n = 0; n < 200; n++)
g (n);
return 0;
}
$ gcc -O2 -g -pg -o test2 test2.c
$ /usr/bin/time ./test2
0.23user 7.37system 0:07.61elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+106minor)pagefaults 0swaps
These examples obviously shows that gprof results are very strange at least. Can
anyone explain them ?
--
Summary: Strange profiling results
Product: binutils
Version: 2.17
Status: NEW
Severity: normal
Priority: P2
Component: gprof
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: dmantipov at yandex dot ru
CC: bug-binutils at gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://sourceware.org/bugzilla/show_bug.cgi?id=2776
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
