You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(6) |
2
(10) |
3
(4) |
|
4
|
5
|
6
|
7
|
8
|
9
(2) |
10
|
|
11
|
12
(6) |
13
(5) |
14
(2) |
15
(4) |
16
(3) |
17
(1) |
|
18
|
19
(1) |
20
(6) |
21
(4) |
22
|
23
|
24
(2) |
|
25
|
26
(4) |
27
(10) |
28
(12) |
29
(29) |
30
(6) |
|
|
From: Peter K. <ja...@su...> - 2010-04-28 15:26:36
|
>>>>> "Tom" == Tom Hughes <to...@co...> writes: Hi, Tom> Please put a ticket in bugzilla and attach your patch to it otherwise Tom> it's likely to wind up getting forgotten. Ok, done: https://bugs.kde.org/show_bug.cgi?id=235642 -- Bye, Peter Korsgaard |
|
From: Tom H. <to...@co...> - 2010-04-28 15:12:25
|
On 28/04/10 15:50, Peter Korsgaard wrote: > The Linux kernel evdev input subsystem provides a number of EVIOCG* > ioctls, which are variable length (returning strings and bitmasks) > and returns the length written instead of the more common 0 on success. > > Add special case handling of these in POST(ioctl) so we don't get > unitialized value(s) warnings when these are used. Please put a ticket in bugzilla and attach your patch to it otherwise it's likely to wind up getting forgotten. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Peter K. <ja...@su...> - 2010-04-28 14:51:06
|
The Linux kernel evdev input subsystem provides a number of EVIOCG*
ioctls, which are variable length (returning strings and bitmasks)
and returns the length written instead of the more common 0 on success.
Add special case handling of these in POST(ioctl) so we don't get
unitialized value(s) warnings when these are used.
Signed-off-by: Peter Korsgaard <ja...@su...>
---
coregrind/m_syswrap/syswrap-linux.c | 30 +++++++++++++++++++++++++++++-
include/vki/vki-linux.h | 25 +++++++++++++++++++++++++
2 files changed, 54 insertions(+), 1 deletions(-)
diff --git a/coregrind/m_syswrap/syswrap-linux.c b/coregrind/m_syswrap/syswrap-linux.c
index e6ee2e7..32af62a 100644
--- a/coregrind/m_syswrap/syswrap-linux.c
+++ b/coregrind/m_syswrap/syswrap-linux.c
@@ -5607,7 +5607,35 @@ POST(sys_ioctl)
break;
default:
- ML_(POST_unknown_ioctl)(tid, RES, ARG2, ARG3);
+ /* EVIOC* are variable length and return size written on success */
+ switch (ARG2 & ~(_VKI_IOC_SIZEMASK << _VKI_IOC_SIZESHIFT)) {
+ case VKI_EVIOCGNAME:
+ case VKI_EVIOCGPHYS:
+ case VKI_EVIOCGUNIQ:
+ case VKI_EVIOCGKEY:
+ case VKI_EVIOCGLED:
+ case VKI_EVIOCGSND:
+ case VKI_EVIOCGSW:
+ case VKI_EVIOCGBIT_SYN:
+ case VKI_EVIOCGBIT_KEY:
+ case VKI_EVIOCGBIT_REL:
+ case VKI_EVIOCGBIT_ABS:
+ case VKI_EVIOCGBIT_MSC:
+ case VKI_EVIOCGBIT_SW:
+ case VKI_EVIOCGBIT_LED:
+ case VKI_EVIOCGBIT_SND:
+ case VKI_EVIOCGBIT_REP:
+ case VKI_EVIOCGBIT_FF:
+ case VKI_EVIOCGBIT_PWR:
+ case VKI_EVIOCGBIT_FFSTATUS:
+ if (RES > 0)
+ POST_MEM_WRITE(ARG3, RES);
+ break;
+
+ default:
+ ML_(POST_unknown_ioctl)(tid, RES, ARG2, ARG3);
+ break;
+ }
break;
}
}
diff --git a/include/vki/vki-linux.h b/include/vki/vki-linux.h
index 7ea6e2a..23b257c 100644
--- a/include/vki/vki-linux.h
+++ b/include/vki/vki-linux.h
@@ -2643,6 +2643,31 @@ struct vki_getcpu_cache {
unsigned long blob[128 / sizeof(long)];
};
+//----------------------------------------------------------------------
+// From linux-2.6.33.3/include/linux/input.h
+//----------------------------------------------------------------------
+
+/* EVIOC* are variable length and return size written on success */
+#define VKI_EVIOCGNAME _VKI_IOC(_VKI_IOC_READ, 'E', 0x06, 0)
+#define VKI_EVIOCGPHYS _VKI_IOC(_VKI_IOC_READ, 'E', 0x07, 0)
+#define VKI_EVIOCGUNIQ _VKI_IOC(_VKI_IOC_READ, 'E', 0x08, 0)
+#define VKI_EVIOCGKEY _VKI_IOC(_VKI_IOC_READ, 'E', 0x18, 0)
+#define VKI_EVIOCGLED _VKI_IOC(_VKI_IOC_READ, 'E', 0x19, 0)
+#define VKI_EVIOCGSND _VKI_IOC(_VKI_IOC_READ, 'E', 0x1a, 0)
+#define VKI_EVIOCGSW _VKI_IOC(_VKI_IOC_READ, 'E', 0x1b, 0)
+#define VKI_EVIOCGBIT_SYN _VKI_IOC(_VKI_IOC_READ, 'E', 0x20, 0)
+#define VKI_EVIOCGBIT_KEY _VKI_IOC(_VKI_IOC_READ, 'E', 0x21, 0)
+#define VKI_EVIOCGBIT_REL _VKI_IOC(_VKI_IOC_READ, 'E', 0x22, 0)
+#define VKI_EVIOCGBIT_ABS _VKI_IOC(_VKI_IOC_READ, 'E', 0x23, 0)
+#define VKI_EVIOCGBIT_MSC _VKI_IOC(_VKI_IOC_READ, 'E', 0x24, 0)
+#define VKI_EVIOCGBIT_SW _VKI_IOC(_VKI_IOC_READ, 'E', 0x25, 0)
+#define VKI_EVIOCGBIT_LED _VKI_IOC(_VKI_IOC_READ, 'E', 0x31, 0)
+#define VKI_EVIOCGBIT_SND _VKI_IOC(_VKI_IOC_READ, 'E', 0x32, 0)
+#define VKI_EVIOCGBIT_REP _VKI_IOC(_VKI_IOC_READ, 'E', 0x34, 0)
+#define VKI_EVIOCGBIT_FF _VKI_IOC(_VKI_IOC_READ, 'E', 0x35, 0)
+#define VKI_EVIOCGBIT_PWR _VKI_IOC(_VKI_IOC_READ, 'E', 0x36, 0)
+#define VKI_EVIOCGBIT_FFSTATUS _VKI_IOC(_VKI_IOC_READ, 'E', 0x37, 0)
+
#endif // __VKI_LINUX_H
/*--------------------------------------------------------------------*/
--
1.7.0
|
|
From: Konstantin S. <kon...@gm...> - 2010-04-28 11:55:48
|
On Wed, Apr 28, 2010 at 2:10 PM, Josef Weidendorfer < Jos...@gm...> wrote: > Hi Konstantin, > > On Tuesday 27 April 2010, Konstantin Serebryany wrote: > > In case you are curious: with PIN we rely on the fact that SBs are > > acyclic and it helps a lot. > > I've described the details here: > > > http://code.google.com/p/data-race-test/wiki/ThreadSanitizerAlgorithm#Instrumentation:_TRACEs > > I just read this thread, but I am still confused. > What is the problem with > > > BB1: > > L: > > code; > > goto L; > > ? The "goto" ends the SB (even with unrolling, the SB will end after a > constant low > number of repetitions of "code"), and following your description of your > "TRACES", > I suppose that the goto also ends your TRACE. Where is the cycle here you > want to avoid? > Ouch! After reading your message I realized that there was a bug in my instrumentation code.... Essentially I was doing OnTrace(); L: code; goto L; instead of L: OnTrace(); code; goto L; So, looks like valgrind gives me what I want! Sorry for disturbing you all and thanks! --kcc > > Josef > |
|
From: <sv...@va...> - 2010-04-28 08:09:39
|
Author: tom
Date: 2010-04-28 09:09:30 +0100 (Wed, 28 Apr 2010)
New Revision: 11106
Log:
Add some basic DWARF4 support. Based on patch from Jakub Jelinek
but with support for VLIW architectures with multiple opcodes per
instruction removed. Fixes #233595.
Modified:
trunk/coregrind/m_debuginfo/d3basics.c
trunk/coregrind/m_debuginfo/priv_d3basics.h
trunk/coregrind/m_debuginfo/readdwarf.c
trunk/coregrind/m_debuginfo/readdwarf3.c
Modified: trunk/coregrind/m_debuginfo/d3basics.c
===================================================================
--- trunk/coregrind/m_debuginfo/d3basics.c 2010-04-19 08:43:26 UTC (rev 11105)
+++ trunk/coregrind/m_debuginfo/d3basics.c 2010-04-28 08:09:30 UTC (rev 11106)
@@ -124,6 +124,10 @@
case DW_TAG_imported_unit: return "DW_TAG_imported_unit";
case DW_TAG_condition: return "DW_TAG_condition";
case DW_TAG_shared_type: return "DW_TAG_shared_type";
+ /* DWARF 4. */
+ case DW_TAG_type_unit: return "DW_TAG_type_unit";
+ case DW_TAG_rvalue_reference_type: return "DW_TAG_rvalue_reference_type";
+ case DW_TAG_template_alias: return "DW_TAG_template_alias";
/* SGI/MIPS Extensions. */
case DW_TAG_MIPS_loop: return "DW_TAG_MIPS_loop";
/* HP extensions. See:
@@ -172,6 +176,10 @@
case DW_FORM_ref8: return "DW_FORM_ref8";
case DW_FORM_ref_udata: return "DW_FORM_ref_udata";
case DW_FORM_indirect: return "DW_FORM_indirect";
+ case DW_FORM_sec_offset:return "DW_FORM_sec_offset";
+ case DW_FORM_exprloc: return "DW_FORM_exprloc";
+ case DW_FORM_flag_present:return "DW_FORM_flag_present";
+ case DW_FORM_ref_sig8: return "DW_FORM_ref_sig8";
default: return "DW_FORM_???";
}
}
@@ -269,6 +277,13 @@
case DW_AT_elemental: return "DW_AT_elemental";
case DW_AT_pure: return "DW_AT_pure";
case DW_AT_recursive: return "DW_AT_recursive";
+ /* DWARF 4 values. */
+ case DW_AT_signature: return "DW_AT_signature";
+ case DW_AT_main_subprogram: return "DW_AT_main_subprogram";
+ case DW_AT_data_bit_offset: return "DW_AT_data_bit_offset";
+ case DW_AT_const_expr: return "DW_AT_const_expr";
+ case DW_AT_enum_class: return "DW_AT_enum_class";
+ case DW_AT_linkage_name: return "DW_AT_linkage_name";
/* SGI/MIPS extensions. */
/* case DW_AT_MIPS_fde: return "DW_AT_MIPS_fde"; */
/* DW_AT_MIPS_fde == DW_AT_HP_unmodifiable */
Modified: trunk/coregrind/m_debuginfo/priv_d3basics.h
===================================================================
--- trunk/coregrind/m_debuginfo/priv_d3basics.h 2010-04-19 08:43:26 UTC (rev 11105)
+++ trunk/coregrind/m_debuginfo/priv_d3basics.h 2010-04-28 08:09:30 UTC (rev 11106)
@@ -104,6 +104,10 @@
DW_TAG_imported_unit = 0x3d,
DW_TAG_condition = 0x3f,
DW_TAG_shared_type = 0x40,
+ /* DWARF 4. */
+ DW_TAG_type_unit = 0x41,
+ DW_TAG_rvalue_reference_type = 0x42,
+ DW_TAG_template_alias = 0x43,
/* SGI/MIPS Extensions. */
DW_TAG_MIPS_loop = 0x4081,
/* HP extensions. See: ftp://ftp.hp.com/pub/lang/tools/WDB/wdb-4.0.tar.gz . */
@@ -158,6 +162,8 @@
DW_LANG_ObjC_plus_plus = 0x0011,
DW_LANG_UPC = 0x0012,
DW_LANG_D = 0x0013,
+ /* DWARF 4. */
+ DW_LANG_Python = 0x0014,
/* MIPS. */
DW_LANG_Mips_Assembler = 0x8001,
/* UPC. */
@@ -188,7 +194,12 @@
DW_FORM_ref4 = 0x13,
DW_FORM_ref8 = 0x14,
DW_FORM_ref_udata = 0x15,
- DW_FORM_indirect = 0x16
+ DW_FORM_indirect = 0x16,
+ /* DWARF 4 values. */
+ DW_FORM_sec_offset = 0x17,
+ DW_FORM_exprloc = 0x18,
+ DW_FORM_flag_present = 0x19,
+ DW_FORM_ref_sig8 = 0x20
}
DW_FORM;
@@ -285,6 +296,13 @@
DW_AT_elemental = 0x66,
DW_AT_pure = 0x67,
DW_AT_recursive = 0x68,
+ /* DWARF 4 values. */
+ DW_AT_signature = 0x69,
+ DW_AT_main_subprogram = 0x6a,
+ DW_AT_data_bit_offset = 0x6b,
+ DW_AT_const_expr = 0x6c,
+ DW_AT_enum_class = 0x6d,
+ DW_AT_linkage_name = 0x6e,
/* SGI/MIPS extensions. */
DW_AT_MIPS_fde = 0x2001,
DW_AT_MIPS_loop_begin = 0x2002,
Modified: trunk/coregrind/m_debuginfo/readdwarf.c
===================================================================
--- trunk/coregrind/m_debuginfo/readdwarf.c 2010-04-19 08:43:26 UTC (rev 11105)
+++ trunk/coregrind/m_debuginfo/readdwarf.c 2010-04-28 08:09:30 UTC (rev 11106)
@@ -1,6 +1,6 @@
/*--------------------------------------------------------------------*/
-/*--- Read DWARF1/2/3 debug info. readdwarf.c ---*/
+/*--- Read DWARF1/2/3/4 debug info. readdwarf.c ---*/
/*--------------------------------------------------------------------*/
/*
@@ -139,6 +139,7 @@
UShort li_version;
ULong li_header_length;
UChar li_min_insn_length;
+ UChar li_max_ops_per_insn;
UChar li_default_is_stmt;
Int li_line_base;
UChar li_line_range;
@@ -182,7 +183,8 @@
{
DW_LNE_end_sequence = 1,
DW_LNE_set_address = 2,
- DW_LNE_define_file = 3
+ DW_LNE_define_file = 3,
+ DW_LNE_set_discriminator = 4
};
typedef struct
@@ -199,7 +201,7 @@
UInt column;
Int is_stmt;
Int basic_block;
- Int end_sequence;
+ UChar end_sequence;
} LineSMR;
@@ -411,6 +413,11 @@
VG_(printf)(" DWARF2-line: set_address\n");
break;
+ case DW_LNE_set_discriminator:
+ read_leb128 (data, & bytes_read, 0);
+ data += bytes_read;
+ break;
+
default:
if (di->ddump_line)
VG_(printf)("process_extended_line_op:default\n");
@@ -513,9 +520,9 @@
VG_(printf)(" DWARF Version: %d\n",
(Int)info.li_version);
- if (info.li_version != 2 && info.li_version != 3) {
+ if (info.li_version != 2 && info.li_version != 3 && info.li_version != 4) {
ML_(symerr)(di, True,
- "Only DWARF version 2 and 3 line info "
+ "Only DWARF version 2, 3 and 4 line info "
"is currently supported.");
goto out;
}
@@ -533,6 +540,26 @@
VG_(printf)(" Minimum Instruction Length: %d\n",
(Int)info.li_min_insn_length);
+ /* We only support machines with one opcode per instruction
+ for now. If we ever want to support VLIW machines there is
+ code to handle multiple opcodes per instruction in the
+ patch attached to BZ#233595.
+ */
+ if (info.li_version >= 4) {
+ info.li_max_ops_per_insn = * ((UChar *)external);
+ if (info.li_max_ops_per_insn != 1) {
+ ML_(symerr)(di, True,
+ "Invalid Maximum Ops Per Insn in line info.");
+ goto out;
+ }
+ external += 1;
+ if (di->ddump_line)
+ VG_(printf)(" Maximum Ops Per Insn: %d\n",
+ (Int)info.li_max_ops_per_insn);
+ } else {
+ info.li_max_ops_per_insn = 1;
+ }
+
info.li_default_is_stmt = * ((UChar *)external);
external += 1;
if (di->ddump_line)
@@ -714,7 +741,7 @@
Int advAddr;
op_code -= info.li_opcode_base;
- adv = (op_code / info.li_line_range)
+ adv = (op_code / info.li_line_range)
* info.li_min_insn_length;
advAddr = adv;
state_machine_regs.address += adv;
@@ -800,7 +827,7 @@
break;
case DW_LNS_advance_pc:
- adv = info.li_min_insn_length
+ adv = info.li_min_insn_length
* read_leb128 (data, & bytes_read, 0);
data += bytes_read;
state_machine_regs.address += adv;
@@ -979,7 +1006,7 @@
blklen = read_initial_length_field( p, &ui->dw64 );
p += ui->dw64 ? 12 : 4;
- /* version should be 2 */
+ /* version should be 2, 3 or 4 */
ver = *((UShort*)p);
p += 2;
@@ -1049,6 +1076,9 @@
classes) use FORM_data8, not FORM_data4. Also,
FORM_ref_addr and FORM_strp are 64-bit values, not 32-bit
values. */
+ /* TJH 27 Apr 10: in DWARF 4 lineptr (and loclistptr,macptr,
+ rangelistptr classes) use FORM_sec_offset which is 64 bits
+ in 64 bit DWARF and 32 bits in 32 bit DWARF. */
switch( form ) {
/* Those cases extract the data properly */
case 0x05: /* FORM_data2 */ cval = *((UShort*)p); p +=2; break;
@@ -1066,7 +1096,11 @@
case 0x08: /* FORM_string */ sval = (Char*)p;
p += VG_(strlen)((Char*)p) + 1; break;
case 0x0b: /* FORM_data1 */ cval = *p; p++; break;
-
+ case 0x17: /* FORM_sec_offset */if (ui->dw64) {
+ cval = *((ULong*)p); p += 8;
+ } else {
+ cval = *((UInt*)p); p += 4;
+ }; break;
/* TODO : Following ones just skip data - implement if you need */
case 0x01: /* FORM_addr */ p += addr_size; break;
case 0x03: /* FORM_block2 */ p += *((UShort*)p) + 2; break;
@@ -1085,7 +1119,10 @@
case 0x13: /* FORM_ref4 */ p += 4; break;
case 0x14: /* FORM_ref8 */ p += 8; break;
case 0x15: /* FORM_ref_udata */ read_leb128U( &p ); break;
-
+ case 0x18: /* FORM_exprloc */ p += read_leb128U( &p ); break;
+ case 0x19: /* FORM_flag_present */break;
+ case 0x20: /* FORM_ref_sig8 */ p += 8; break;
+
default:
VG_(printf)( "### unhandled dwarf2 abbrev form code 0x%x\n", form );
break;
@@ -1163,9 +1200,9 @@
/* version should be 2 */
ver = *((UShort*)( block_img + blklen_len ));
- if ( ver != 2 && ver != 3 ) {
+ if ( ver != 2 && ver != 3 && ver != 4 ) {
ML_(symerr)( di, True,
- "Ignoring non-Dwarf2/3 block in .debug_info" );
+ "Ignoring non-Dwarf2/3/4 block in .debug_info" );
continue;
}
@@ -3705,8 +3742,8 @@
VG_(printf)("cie.version = %d\n", (Int)cie_version);
if (di->ddump_frames)
VG_(printf)(" Version: %d\n", (Int)cie_version);
- if (cie_version != 1 && cie_version != 3) {
- how = "unexpected CIE version (not 1 nor 3)";
+ if (cie_version != 1 && cie_version != 3 && cie_version != 4) {
+ how = "unexpected CIE version (not 1 nor 3 nor 4)";
goto bad;
}
@@ -3722,6 +3759,19 @@
cie_augmentation += 2;
}
+ if (cie_version >= 4) {
+ if (read_UChar(data) != sizeof(Addr)) {
+ how = "unexpected address size";
+ goto bad;
+ }
+ data += sizeof(UChar);
+ if (read_UChar(data) != 0) {
+ how = "unexpected non-zero segment size";
+ goto bad;
+ }
+ data += sizeof(UChar);
+ }
+
the_CIEs[this_CIE].code_a_f = read_leb128( data, &nbytes, 0);
data += nbytes;
if (di->trace_cfi)
Modified: trunk/coregrind/m_debuginfo/readdwarf3.c
===================================================================
--- trunk/coregrind/m_debuginfo/readdwarf3.c 2010-04-19 08:43:26 UTC (rev 11105)
+++ trunk/coregrind/m_debuginfo/readdwarf3.c 2010-04-28 08:09:30 UTC (rev 11106)
@@ -1,6 +1,6 @@
/*--------------------------------------------------------------------*/
-/*--- Read DWARF3 ".debug_info" sections (DIE trees). ---*/
+/*--- Read DWARF3/4 ".debug_info" sections (DIE trees). ---*/
/*--- readdwarf3.c ---*/
/*--------------------------------------------------------------------*/
@@ -387,7 +387,7 @@
void (*barf)( HChar* ) __attribute__((noreturn));
/* Is this 64-bit DWARF ? */
Bool is_dw64;
- /* Which DWARF version ? (2 or 3) */
+ /* Which DWARF version ? (2, 3 or 4) */
UShort version;
/* Length of this Compilation Unit, as stated in the
.unit_length :: InitialLength field of the CU Header.
@@ -805,8 +805,8 @@
/* version */
cc->version = get_UShort( c );
- if (cc->version != 2 && cc->version != 3)
- cc->barf( "parse_CU_Header: is neither DWARF2 nor DWARF3" );
+ if (cc->version != 2 && cc->version != 3 && cc->version != 4)
+ cc->barf( "parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4" );
TRACE_D3(" Version: %d\n", (Int)cc->version );
/* debug_abbrev_offset */
@@ -984,11 +984,21 @@
*ctsSzB = 8;
TRACE_D3("%llu", *cts);
break;
+ case DW_FORM_sec_offset:
+ *cts = (ULong)get_Dwarfish_UWord( c, cc->is_dw64 );
+ *ctsSzB = cc->is_dw64 ? 8 : 4;
+ TRACE_D3("%llu", *cts);
+ break;
case DW_FORM_sdata:
*cts = (ULong)(Long)get_SLEB128(c);
*ctsSzB = 8;
TRACE_D3("%lld", (Long)*cts);
break;
+ case DW_FORM_udata:
+ *cts = (ULong)(Long)get_ULEB128(c);
+ *ctsSzB = 8;
+ TRACE_D3("%llu", (Long)*cts);
+ break;
case DW_FORM_addr:
/* note, this is a hack. DW_FORM_addr is defined as getting
a word the size of the target machine as defined by the
@@ -1055,6 +1065,22 @@
*ctsMemSzB = 1 + (ULong)VG_(strlen)(str);
break;
}
+ case DW_FORM_ref1: {
+ UChar u8 = get_UChar(c);
+ UWord res = cc->cu_start_offset + (UWord)u8;
+ *cts = (ULong)res;
+ *ctsSzB = sizeof(UWord);
+ TRACE_D3("<%lx>", res);
+ break;
+ }
+ case DW_FORM_ref2: {
+ UShort u16 = get_UShort(c);
+ UWord res = cc->cu_start_offset + (UWord)u16;
+ *cts = (ULong)res;
+ *ctsSzB = sizeof(UWord);
+ TRACE_D3("<%lx>", res);
+ break;
+ }
case DW_FORM_ref4: {
UInt u32 = get_UInt(c);
UWord res = cc->cu_start_offset + (UWord)u32;
@@ -1063,6 +1089,22 @@
TRACE_D3("<%lx>", res);
break;
}
+ case DW_FORM_ref8: {
+ ULong u64 = get_ULong(c);
+ UWord res = cc->cu_start_offset + (UWord)u64;
+ *cts = (ULong)res;
+ *ctsSzB = sizeof(UWord);
+ TRACE_D3("<%lx>", res);
+ break;
+ }
+ case DW_FORM_ref_udata: {
+ ULong u64 = get_ULEB128(c);
+ UWord res = cc->cu_start_offset + (UWord)u64;
+ *cts = (ULong)res;
+ *ctsSzB = sizeof(UWord);
+ TRACE_D3("<%lx>", res);
+ break;
+ }
case DW_FORM_flag: {
UChar u8 = get_UChar(c);
TRACE_D3("%u", (UInt)u8);
@@ -1070,6 +1112,11 @@
*ctsSzB = 1;
break;
}
+ case DW_FORM_flag_present:
+ TRACE_D3("1");
+ *cts = 1;
+ *ctsSzB = 1;
+ break;
case DW_FORM_block1: {
ULong u64b;
ULong u64 = (ULong)get_UChar(c);
@@ -1096,6 +1143,50 @@
*ctsMemSzB = (UWord)u64;
break;
}
+ case DW_FORM_block4: {
+ ULong u64b;
+ ULong u64 = (ULong)get_UInt(c);
+ UChar* block = get_address_of_Cursor(c);
+ TRACE_D3("%llu byte block: ", u64);
+ for (u64b = u64; u64b > 0; u64b--) {
+ UChar u8 = get_UChar(c);
+ TRACE_D3("%x ", (UInt)u8);
+ }
+ *cts = (ULong)(UWord)block;
+ *ctsMemSzB = (UWord)u64;
+ break;
+ }
+ case DW_FORM_exprloc:
+ case DW_FORM_block: {
+ ULong u64b;
+ ULong u64 = (ULong)get_ULEB128(c);
+ UChar* block = get_address_of_Cursor(c);
+ TRACE_D3("%llu byte block: ", u64);
+ for (u64b = u64; u64b > 0; u64b--) {
+ UChar u8 = get_UChar(c);
+ TRACE_D3("%x ", (UInt)u8);
+ }
+ *cts = (ULong)(UWord)block;
+ *ctsMemSzB = (UWord)u64;
+ break;
+ }
+ case DW_FORM_ref_sig8: {
+ ULong u64b;
+ UChar* block = get_address_of_Cursor(c);
+ TRACE_D3("8 byte signature: ");
+ for (u64b = 8; u64b > 0; u64b--) {
+ UChar u8 = get_UChar(c);
+ TRACE_D3("%x ", (UInt)u8);
+ }
+ *cts = (ULong)(UWord)block;
+ *ctsMemSzB = 8;
+ break;
+ }
+ case DW_FORM_indirect:
+ get_Form_contents (cts, ctsSzB, ctsMemSzB, cc, c, td3,
+ (DW_FORM)get_ULEB128(c));
+ return;
+
default:
VG_(printf)(
"get_Form_contents: unhandled %d (%s) at <%lx>\n",
@@ -1322,11 +1413,13 @@
get_Initial_Length( &is_dw64, &c,
"read_filename_table: invalid initial-length field" );
version = get_UShort( &c );
- if (version != 2 && version != 3)
- cc->barf("read_filename_table: Only DWARF version 2 and 3 line info "
+ if (version != 2 && version != 3 && version != 4)
+ cc->barf("read_filename_table: Only DWARF version 2, 3 and 4 line info "
"is currently supported.");
/*header_length = (ULong)*/ get_Dwarfish_UWord( &c, is_dw64 );
/*minimum_instruction_length = */ get_UChar( &c );
+ if (version >= 4)
+ /*maximum_operations_per_insn = */ get_UChar( &c );
/*default_is_stmt = */ get_UChar( &c );
/*line_base = (Char)*/ get_UChar( &c );
/*line_range = */ get_UChar( &c );
@@ -2025,7 +2118,7 @@
case DW_LANG_C89: case DW_LANG_C:
case DW_LANG_C_plus_plus: case DW_LANG_ObjC:
case DW_LANG_ObjC_plus_plus: case DW_LANG_UPC:
- case DW_LANG_Upc:
+ case DW_LANG_Upc: case DW_LANG_C99:
parser->language = 'C'; break;
case DW_LANG_Fortran77: case DW_LANG_Fortran90:
case DW_LANG_Fortran95:
@@ -2033,8 +2126,8 @@
case DW_LANG_Ada83: case DW_LANG_Cobol74:
case DW_LANG_Cobol85: case DW_LANG_Pascal83:
case DW_LANG_Modula2: case DW_LANG_Java:
- case DW_LANG_C99: case DW_LANG_Ada95:
- case DW_LANG_PLI: case DW_LANG_D:
+ case DW_LANG_Ada95: case DW_LANG_PLI:
+ case DW_LANG_D: case DW_LANG_Python:
case DW_LANG_Mips_Assembler:
parser->language = '?'; break;
default:
|
|
From: Konstantin S. <kon...@gm...> - 2010-04-28 07:09:28
|
On Wed, Apr 28, 2010 at 11:20 AM, Julian Seward <js...@ac...> wrote: > On Wednesday 28 April 2010, Konstantin Serebryany wrote: > > On Wed, Apr 28, 2010 at 10:27 AM, Julian Seward <js...@ac...> wrote: > > > > > Can you show an IR example which illustrates what you mean? > > > > > eg, what does the IR that you want look like, for this example? > > > > > > > > Consider an SB which looks like this: > > > > > > > > BB1: > > > > L: > > > > code; > > > > goto L; > > > > > > > > Can valgrind create two SBs for this case? > > > > BB1: > > > > L: > > > > code; > > > > goto L1 > > > > > > > > BB2: > > > > L1: > > > > goto L > > > > > > No, I don't think it will do that exactly. > > > > Yes, it won't do it now. > > Is it possible to change V so that it does? > > Uh, you mean you want some functionality like that to be added? > Yep. > > In general (to try to answer the original question), in the general > case an IRSB can contain IR for guest insns with the following > characteristics: > > * between 1 and 50 guest instructions; longer IRSBs are truncated > > * from up to 3 contiguous address ranges (it will chase over jumps/calls) > > * each guest insn may appear more than once, if the IRSB is unrolled > > * with --vex-guest-chase-cond=yes, it will chase also across > conditional branches; this again may cause guest insns to appear > more than once > > * in all cases, the IR for each insn is starts with an IRStmt_IMark, > so by examining those you can find out exactly what is going on > > J > |
|
From: Julian S. <js...@ac...> - 2010-04-28 07:05:00
|
On Wednesday 28 April 2010, Konstantin Serebryany wrote: > On Wed, Apr 28, 2010 at 10:27 AM, Julian Seward <js...@ac...> wrote: > > > > Can you show an IR example which illustrates what you mean? > > > > eg, what does the IR that you want look like, for this example? > > > > > > Consider an SB which looks like this: > > > > > > BB1: > > > L: > > > code; > > > goto L; > > > > > > Can valgrind create two SBs for this case? > > > BB1: > > > L: > > > code; > > > goto L1 > > > > > > BB2: > > > L1: > > > goto L > > > > No, I don't think it will do that exactly. > > Yes, it won't do it now. > Is it possible to change V so that it does? Uh, you mean you want some functionality like that to be added? In general (to try to answer the original question), in the general case an IRSB can contain IR for guest insns with the following characteristics: * between 1 and 50 guest instructions; longer IRSBs are truncated * from up to 3 contiguous address ranges (it will chase over jumps/calls) * each guest insn may appear more than once, if the IRSB is unrolled * with --vex-guest-chase-cond=yes, it will chase also across conditional branches; this again may cause guest insns to appear more than once * in all cases, the IR for each insn is starts with an IRStmt_IMark, so by examining those you can find out exactly what is going on J |
|
From: Konstantin S. <kon...@gm...> - 2010-04-28 06:31:53
|
On Wed, Apr 28, 2010 at 10:27 AM, Julian Seward <js...@ac...> wrote: > > > > Can you show an IR example which illustrates what you mean? > > > eg, what does the IR that you want look like, for this example? > > > > Consider an SB which looks like this: > > > > BB1: > > L: > > code; > > goto L; > > > > Can valgrind create two SBs for this case? > > BB1: > > L: > > code; > > goto L1 > > > > BB2: > > L1: > > goto L > > No, I don't think it will do that exactly. Yes, it won't do it now. Is it possible to change V so that it does? > It will do tail duplication > though: if you have (original insns) like this > > A; B; C; D; E > > then a guest branch to A will cause an IRSB for the sequence "A; B; C; D; > E" > to be made. If later there is a jump to C then a new sequence "C; D; E" is > made, so the tail is duplicated. I imagine Pin etc will do the same. > Yes, sure. > > J > --kcc |
|
From: Julian S. <js...@ac...> - 2010-04-28 06:11:45
|
> > Can you show an IR example which illustrates what you mean? > > eg, what does the IR that you want look like, for this example? > > Consider an SB which looks like this: > > BB1: > L: > code; > goto L; > > Can valgrind create two SBs for this case? > BB1: > L: > code; > goto L1 > > BB2: > L1: > goto L No, I don't think it will do that exactly. It will do tail duplication though: if you have (original insns) like this A; B; C; D; E then a guest branch to A will cause an IRSB for the sequence "A; B; C; D; E" to be made. If later there is a jump to C then a new sequence "C; D; E" is made, so the tail is duplicated. I imagine Pin etc will do the same. J |
|
From: Adarsh Y. <ay...@um...> - 2010-04-28 06:10:18
|
In the cg_instrument() function is cg_main() i have added the following code
to recognise function calls:
if (sbIn->jumpkind == Ijk_Call){
VG_(printf)("In jumpkind call\n");
//VG_(printf)(sbIn->jumpkind);
addEvent_Cl( &cgs, curr_inode, sbIn->next );
}
The function addEvent_Cl looks like this:
static
void addEvent_Cl ( CgState* cgs, InstrInfo* inode, IRAtom* whereTo )
{
Event* evt;
if (cgs->events_used == N_EVENTS) flushEvents(cgs);
evt = &cgs->events[cgs->events_used];
VG_(printf)("In add eventCl");
init_Event(evt);
evt->tag = Ev_Cl;
evt->inode = inode;
evt->Ev.Bi.dst = whereTo;
cgs->events_used++;
}
In flushEvents(cgs), i have added a case to add the helper function:
case Ev_Cl:
helperName = "log_Call";
helperAddr = &log_Call;
argv = mkIRExprVec_2( i_node_expr, ev->Ev.Bi.dst
);//ev->Ev.Bc.taken );
regparms = 2;
break;
On Wed, Apr 28, 2010 at 2:19 AM, Julian Seward <js...@ac...> wrote:
> On Tuesday 27 April 2010, Adarsh Yoga wrote:
> > Hi,
> >
> > I am trying to create the tool for predicting return address in Valgrind.
> > All I am doing now is just adding temporary code to the cachegrind tool
> to
> > recognize function calls and return events and act accordingly.
> > The changes are very minimal. But when i run it I am getting an error
> which
> > says that the "Impossible happened!!" and the VEX temporary storage has
> > been exhausted.
>
> That sounds a bit unlikely, unless you have somehow allocated a very
> large number of IR objects during the translation. Or are instrumenting
> a very long basic block. What do your minimal changes look like?
>
> J
>
--
Adarsh Yoga
Graduate Student, Computer Science
Indiana University, Bloomington
|
|
From: Julian S. <js...@ac...> - 2010-04-28 06:03:32
|
On Tuesday 27 April 2010, Adarsh Yoga wrote: > Hi, > > I am trying to create the tool for predicting return address in Valgrind. > All I am doing now is just adding temporary code to the cachegrind tool to > recognize function calls and return events and act accordingly. > The changes are very minimal. But when i run it I am getting an error which > says that the "Impossible happened!!" and the VEX temporary storage has > been exhausted. That sounds a bit unlikely, unless you have somehow allocated a very large number of IR objects during the translation. Or are instrumenting a very long basic block. What do your minimal changes look like? J |