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
(32) |
Oct
|
Nov
|
Dec
|
|
From: Julian S. <jse...@gm...> - 2022-11-27 11:50:40
|
On 27/11/2022 03:09, Eyal Soha wrote: > It's a long and boring research that I did but the result is that I'm going > to change the "mcx_mask" from an array of bits (uint) to an array of ulong Hmm, we shouldn't really need to mess with the mcx_mask at all. What is the test case that shows the problem? J |
|
From: Eyal S. <eya...@gm...> - 2022-11-27 02:09:20
|
Okay, I've figured it out. Thanks for your help! It's a long and boring research that I did but the result is that I'm going to change the "mcx_mask" from an array of bits (uint) to an array of ulong so that we can be more precise. This ought to solve the problem. Let me know if you want more details. I'll get some code ready and send it out for review. Maybe it'll get accepted? If you're curious, here are all the other improvements that I have made to valgrind in my branch. Maybe they could get merged, too? https://github.com/eyal0/valgrind/commit/4f130b5b5ea6be2c0c93f6359a88f7a2e51e459e https://github.com/eyal0/valgrind/commit/eccc56d407f2b2f277765bc0dae42cadb86c133a https://github.com/eyal0/valgrind/commit/c3a5f06e4620599339601640e9a18c383ecb4e2e Thanks again for your explanation! Eyal On Sat, Nov 26, 2022 at 2:36 PM Mark Wielaard <ma...@kl...> wrote: > Hi Eyal, > > On Sat, Nov 26, 2022 at 01:22:51PM -0700, Eyal Soha wrote: > > I found a false positive in amd64 conditional move. I'm comfortable > fixing > > it if I can just find how the cmov gets translated into IR for memcheck. > > I've done work on other IR before but I'm having the hardest time just > > finding where this code is generated! > > > > The issue is that the sign flag is depending upon all bits being defined > > where actually it only needs the highest bit. > > > > Where can I find how cmovnz translates to the valid bit checking IR? If > > there are docs that will help me, I'm happy to read them. And if not, > I'll > > make docs to describe whatever I'm taught. > > The amd64 code is transformed into VEX IR in > VEX/priv/guest_amd64_toIR.c. Look for "cmov not zero" to find > cmovnz. Which will call dis_cmov_E_G which uses > mk_amd64g_calculate_condition. The actual IR created is described in > VEX/pub/libvex_ir.h. The code that instruments this IR for memcheck > definedness checking is in memcheck/mc_translate.c. > > README_DEVELOPERS has some hints at the end about Printing out > problematic blocks. valgrind can print out various stages of the IR, > which is really helpful tracking down where which transformation > occurs. > > Cheers, > > Mark > |
|
From: Mark W. <ma...@kl...> - 2022-11-26 21:36:20
|
Hi Eyal, On Sat, Nov 26, 2022 at 01:22:51PM -0700, Eyal Soha wrote: > I found a false positive in amd64 conditional move. I'm comfortable fixing > it if I can just find how the cmov gets translated into IR for memcheck. > I've done work on other IR before but I'm having the hardest time just > finding where this code is generated! > > The issue is that the sign flag is depending upon all bits being defined > where actually it only needs the highest bit. > > Where can I find how cmovnz translates to the valid bit checking IR? If > there are docs that will help me, I'm happy to read them. And if not, I'll > make docs to describe whatever I'm taught. The amd64 code is transformed into VEX IR in VEX/priv/guest_amd64_toIR.c. Look for "cmov not zero" to find cmovnz. Which will call dis_cmov_E_G which uses mk_amd64g_calculate_condition. The actual IR created is described in VEX/pub/libvex_ir.h. The code that instruments this IR for memcheck definedness checking is in memcheck/mc_translate.c. README_DEVELOPERS has some hints at the end about Printing out problematic blocks. valgrind can print out various stages of the IR, which is really helpful tracking down where which transformation occurs. Cheers, Mark |
|
From: Eyal S. <eya...@gm...> - 2022-11-26 20:23:13
|
I found a false positive in amd64 conditional move. I'm comfortable fixing it if I can just find how the cmov gets translated into IR for memcheck. I've done work on other IR before but I'm having the hardest time just finding where this code is generated! The issue is that the sign flag is depending upon all bits being defined where actually it only needs the highest bit. Where can I find how cmovnz translates to the valid bit checking IR? If there are docs that will help me, I'm happy to read them. And if not, I'll make docs to describe whatever I'm taught. Thanks! Eyal |
|
From: Mark W. <ma...@so...> - 2022-11-18 19:18:27
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=0811a612dd7ce0c02a5dd699b34e660c742df8fe commit 0811a612dd7ce0c02a5dd699b34e660c742df8fe Author: Mark Wielaard <ma...@kl...> Date: Fri Nov 18 20:12:06 2022 +0100 Implicit int in none/tests/faultstatus.c There is a definition in faultstatus.c that is not accepted by C99 compilers (implicit ints were removed in that language revision). https://bugs.kde.org/show_bug.cgi?id=462007 Diff: --- NEWS | 1 + none/tests/faultstatus.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index b8bed8ff0c..40603494b5 100644 --- a/NEWS +++ b/NEWS @@ -80,6 +80,7 @@ n-i-bz Implement vgdb invoker on FreeBSD 458915 Remove register cache to fix 458915 gdbserver causes wrong syscall return 459031 Documentation on --error-exitcode incomplete 459477 XERROR messages lacks ending '\n' in vgdb +462007 Implicit int in none/tests/faultstatus.c To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX diff --git a/none/tests/faultstatus.c b/none/tests/faultstatus.c index 458ea82645..92a8350ab2 100644 --- a/none/tests/faultstatus.c +++ b/none/tests/faultstatus.c @@ -190,7 +190,7 @@ int main() return 0; } -static volatile s_zero; +static volatile int s_zero; static int zero() { |
|
From: Mark W. <ma...@kl...> - 2022-11-15 22:07:27
|
This Friday, 18 November, at 16:00 UTC (11:00am Eastern, 17:00 Central European Time) the FSF will host a session on their BBB server about the current sourceware infrastructure and future plans. https://www.fsf.org/events/sourceware-infrastructure-a-presentation-and-community-q-a https://inbox.sourceware.org/overseers/6e9...@fs.../ We like to discuss how to use the new infrastructure setup this last year, builder, try/ci/full buildbots, bunsen testsuite analysis, patchwork patch tracking, handling patches/email with public-inbox, b4, the sourcehut mirror. And the future of Sourceware as a Software Freedom Conservancy member project. (*) This presentation is for everybody who likes to discuss (and wants to help with) automating the infrastructure to make contributing to our projects more fun and more productive. (*) Similar to the BoF we intended to do at the Cauldron this year: https://gnu.wildebeest.org/~mark/sourceware/presentation.html |
|
From: John R. <jr...@bi...> - 2022-11-15 18:22:32
|
>> ==2214549== valgrind: Unrecognised instruction at address 0x46bc3d9. >> ==2214549== at 0x46BC3D9: __wine_syscall_dispatcher (in /usr/local/lib/wine/x86_64-unix/ntdll.so) > A bug has been entered as https://bugs.kde.org/show_bug.cgi?id=461855 > "(wine xsavec64) vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xC7 0xA1 0xC0 0x0 0x0 0x0 0x48 0xF" Probably the bug should be closed as Invalid; see Comment https://bugs.kde.org/show_bug.cgi?id=461855#c2 The Original Poster is using an ancient version (6 years old) of valgrind that does not print the unrecognized instruction bytes. The program being analyzed is really wine64, not a.out.so, and debug symbols for wine64 are not available. Wine64 requires an "installation" of Microsoft Windows. Altogether a very disappointing episode. |
|
From: John R. <jr...@bi...> - 2022-11-15 03:33:25
|
On 11/1/22 03:31, Mahin Pandya wrote: > ==2214549== valgrind: Unrecognised instruction at address 0x46bc3d9. > ==2214549== at 0x46BC3D9: __wine_syscall_dispatcher (in /usr/local/lib/wine/x86_64-unix/ntdll.so) > ==2214549== by 0x170055EEF: LdrResolveDelayLoadedAPI (loader.c:3515) > ==2214549== Your program just tried to execute an instruction that Valgrind > ==2214549== did not recognise. There are two possible reasons for this. A bug has been entered as https://bugs.kde.org/show_bug.cgi?id=461855 "(wine xsavec64) vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xC7 0xA1 0xC0 0x0 0x0 0x0 0x48 0xF" This might not be the actual problem that Mahin reported (Mahin's report does not include the instruction stream bytes), but Wine definitely does execute unhandled 'xsavec64', so this is a place to start fixing. |
|
From: Paul F. <pa...@so...> - 2022-11-13 06:41:45
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=5ab1e53f07f47c0343f3e4256df42128c3bc172e commit 5ab1e53f07f47c0343f3e4256df42128c3bc172e Author: Paul Floyd <pj...@wa...> Date: Sun Nov 13 07:39:43 2022 +0100 Manual: add FreeBSD to section about Linux stack cache Use macOS rather than Mac OS X Diff: --- docs/xml/manual-core.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/xml/manual-core.xml b/docs/xml/manual-core.xml index 8136c2e089..70253e7c31 100644 --- a/docs/xml/manual-core.xml +++ b/docs/xml/manual-core.xml @@ -1622,9 +1622,9 @@ that can report errors, e.g. Memcheck, but not Cachegrind.</para> </term> <listitem> <para>This option is only relevant when running Valgrind on - Mac OS X.</para> + macOS.</para> - <para>Mac OS X uses a deferred debug information (debuginfo) + <para>macOS uses a deferred debug information (debuginfo) linking scheme. When object files containing debuginfo are linked into a <computeroutput>.dylib</computeroutput> or an executable, the debuginfo is not copied into the final file. @@ -2225,7 +2225,7 @@ need to use them.</para> <listitem> <para><option>no-nptl-pthread-stackcache: </option> This hint is only relevant when running Valgrind on Linux; - it is ignored on Solaris and Mac OS X.</para> + it is ignored on FreeBSD, Solaris and macOS.</para> <para>The GNU glibc pthread library (<function>libpthread.so</function>), which is used by |
|
From: Paul F. <pa...@so...> - 2022-11-12 20:03:08
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=ac6d9faf4b7014d9eb2b7f2a21044460eb67a94b commit ac6d9faf4b7014d9eb2b7f2a21044460eb67a94b Author: Paul Floyd <pj...@wa...> Date: Sat Nov 12 19:24:51 2022 +0100 Bug 351857 - confusing error message about valid command line option Added code to handle missing "=something". Diff: --- NEWS | 1 + drd/drd_main.c | 157 +++++++++++++++++++--------------------- include/pub_tool_options.h | 55 ++++++++++---- memcheck/mc_main.c | 2 +- none/tests/Makefile.am | 5 ++ none/tests/cmdline10.stderr.exp | 3 + none/tests/cmdline10.vgtest | 3 + none/tests/cmdline11.stderr.exp | 3 + none/tests/cmdline11.vgtest | 4 + none/tests/cmdline7.stderr.exp | 2 + none/tests/cmdline7.vgtest | 3 + none/tests/cmdline8.stderr.exp | 2 + none/tests/cmdline8.vgtest | 3 + none/tests/cmdline9.stderr.exp | 3 + none/tests/cmdline9.vgtest | 3 + 15 files changed, 153 insertions(+), 96 deletions(-) diff --git a/NEWS b/NEWS index a421b980c5..b8bed8ff0c 100644 --- a/NEWS +++ b/NEWS @@ -21,6 +21,7 @@ than mailing the developers (or mailing lists) directly -- bugs that are not entered into bugzilla tend to get forgotten about or ignored. 170510 Don't warn about ioctl of size 0 without direction hint +351857 confusing error message about valid command line option 444110 priv/guest_ppc_toIR.c:36198:31: warning: duplicated 'if' condition. 459476 vgdb: allow address reuse to avoid "address already in use" errorsuse" errors diff --git a/drd/drd_main.c b/drd/drd_main.c index 4a71eebb5f..2161e0316e 100644 --- a/drd/drd_main.c +++ b/drd/drd_main.c @@ -65,60 +65,95 @@ static Bool trace_sectsuppr; */ static Bool DRD_(process_cmd_line_option)(const HChar* arg) { - int check_stack_accesses = -1; - int join_list_vol = -1; - int exclusive_threshold_ms = -1; - int first_race_only = -1; - int report_signal_unlocked = -1; - int segment_merging = -1; - int segment_merge_interval = -1; - int shared_threshold_ms = -1; - int show_confl_seg = -1; - int trace_barrier = -1; - int trace_clientobj = -1; - int trace_cond = -1; - int trace_csw = -1; - int trace_fork_join = -1; - int trace_hb = -1; - int trace_conflict_set = -1; - int trace_conflict_set_bm = -1; - int trace_mutex = -1; - int trace_rwlock = -1; - int trace_segment = -1; - int trace_semaphore = -1; - int trace_suppression = -1; + Bool check_stack_accesses = False; + int join_list_vol = -1; + int exclusive_threshold_ms = -1; + Bool first_race_only = False; + Bool report_signal_unlocked = False; + Bool segment_merging = False; + int segment_merge_interval = -1; + int shared_threshold_ms = -1; + Bool show_confl_seg = False; + Bool trace_barrier = False; + Bool trace_clientobj = False; + Bool trace_cond = False; + Bool trace_csw = False; + Bool trace_fork_join = False; + Bool trace_hb = False; + Bool trace_conflict_set = False; + Bool trace_conflict_set_bm = False; + Bool trace_mutex = False; + Bool trace_rwlock = False; + Bool trace_segment = False; + Bool trace_semaphore = False; + Bool trace_suppression = False; const HChar* trace_address = 0; const HChar* ptrace_address= 0; - if VG_BOOL_CLO(arg, "--check-stack-var", check_stack_accesses) {} + if VG_BOOL_CLO(arg, "--check-stack-var", check_stack_accesses) { + DRD_(set_check_stack_accesses)(check_stack_accesses); + } else if VG_INT_CLO (arg, "--join-list-vol", join_list_vol) {} else if VG_BOOL_CLO(arg, "--drd-stats", s_print_stats) {} - else if VG_BOOL_CLO(arg, "--first-race-only", first_race_only) {} + else if VG_BOOL_CLO(arg, "--first-race-only", first_race_only) { + DRD_(set_first_race_only)(first_race_only); + } else if VG_BOOL_CLO(arg, "--free-is-write", DRD_(g_free_is_write)) {} - else if VG_BOOL_CLO(arg,"--report-signal-unlocked",report_signal_unlocked) - {} - else if VG_BOOL_CLO(arg, "--segment-merging", segment_merging) {} + else if VG_BOOL_CLO(arg,"--report-signal-unlocked",report_signal_unlocked) { + DRD_(cond_set_report_signal_unlocked)(report_signal_unlocked); + } + else if VG_BOOL_CLO(arg, "--segment-merging", segment_merging) { + DRD_(thread_set_segment_merging)(segment_merging); + } else if VG_INT_CLO (arg, "--segment-merging-interval", segment_merge_interval) {} - else if VG_BOOL_CLO(arg, "--show-confl-seg", show_confl_seg) {} + else if VG_BOOL_CLO(arg, "--show-confl-seg", show_confl_seg) { + DRD_(set_show_conflicting_segments)(show_confl_seg); + } else if VG_BOOL_CLO(arg, "--show-stack-usage", s_show_stack_usage) {} else if VG_BOOL_CLO(arg, "--ignore-thread-creation", DRD_(ignore_thread_creation)) {} else if VG_BOOL_CLO(arg, "--trace-alloc", s_trace_alloc) {} - else if VG_BOOL_CLO(arg, "--trace-barrier", trace_barrier) {} - else if VG_BOOL_CLO(arg, "--trace-clientobj", trace_clientobj) {} - else if VG_BOOL_CLO(arg, "--trace-cond", trace_cond) {} - else if VG_BOOL_CLO(arg, "--trace-conflict-set", trace_conflict_set) {} - else if VG_BOOL_CLO(arg, "--trace-conflict-set-bm", trace_conflict_set_bm){} - else if VG_BOOL_CLO(arg, "--trace-csw", trace_csw) {} - else if VG_BOOL_CLO(arg, "--trace-fork-join", trace_fork_join) {} - else if VG_BOOL_CLO(arg, "--trace-hb", trace_hb) {} - else if VG_BOOL_CLO(arg, "--trace-mutex", trace_mutex) {} - else if VG_BOOL_CLO(arg, "--trace-rwlock", trace_rwlock) {} + else if VG_BOOL_CLO(arg, "--trace-barrier", trace_barrier) { + DRD_(barrier_set_trace)(trace_barrier); + } + else if VG_BOOL_CLO(arg, "--trace-clientobj", trace_clientobj) { + DRD_(clientobj_set_trace)(trace_clientobj); + } + else if VG_BOOL_CLO(arg, "--trace-cond", trace_cond) { + DRD_(cond_set_trace)(trace_cond); + } + else if VG_BOOL_CLO(arg, "--trace-conflict-set", trace_conflict_set) { + DRD_(thread_trace_conflict_set)(trace_conflict_set); + } + else if VG_BOOL_CLO(arg, "--trace-conflict-set-bm", trace_conflict_set_bm){ + DRD_(thread_trace_conflict_set_bm)(trace_conflict_set_bm); + } + else if VG_BOOL_CLO(arg, "--trace-csw", trace_csw) { + DRD_(thread_trace_context_switches)(trace_csw); + } + else if VG_BOOL_CLO(arg, "--trace-fork-join", trace_fork_join) { + DRD_(thread_set_trace_fork_join)(trace_fork_join); + } + else if VG_BOOL_CLO(arg, "--trace-hb", trace_hb) { + DRD_(hb_set_trace)(trace_hb); + } + else if VG_BOOL_CLO(arg, "--trace-mutex", trace_mutex) { + DRD_(mutex_set_trace)(trace_mutex); + } + else if VG_BOOL_CLO(arg, "--trace-rwlock", trace_rwlock) { + DRD_(rwlock_set_trace)(trace_rwlock); + } else if VG_BOOL_CLO(arg, "--trace-sectsuppr", trace_sectsuppr) {} - else if VG_BOOL_CLO(arg, "--trace-segment", trace_segment) {} - else if VG_BOOL_CLO(arg, "--trace-semaphore", trace_semaphore) {} - else if VG_BOOL_CLO(arg, "--trace-suppr", trace_suppression) {} + else if VG_BOOL_CLO(arg, "--trace-segment", trace_segment) { + DRD_(sg_set_trace)(trace_segment); + } + else if VG_BOOL_CLO(arg, "--trace-semaphore", trace_semaphore) { + DRD_(semaphore_set_trace)(trace_semaphore); + } + else if VG_BOOL_CLO(arg, "--trace-suppr", trace_suppression) { + DRD_(suppression_set_trace)(trace_suppression); + } else if VG_BOOL_CLO(arg, "--var-info", s_var_info) {} else if VG_BOOL_CLO(arg, "--verify-conflict-set", DRD_(verify_conflict_set)) {} @@ -129,33 +164,19 @@ static Bool DRD_(process_cmd_line_option)(const HChar* arg) else return VG_(replacement_malloc_process_cmd_line_option)(arg); - if (check_stack_accesses != -1) - DRD_(set_check_stack_accesses)(check_stack_accesses); if (exclusive_threshold_ms != -1) { DRD_(mutex_set_lock_threshold)(exclusive_threshold_ms); DRD_(rwlock_set_exclusive_threshold)(exclusive_threshold_ms); } - if (first_race_only != -1) - { - DRD_(set_first_race_only)(first_race_only); - } if (join_list_vol != -1) DRD_(thread_set_join_list_vol)(join_list_vol); - if (report_signal_unlocked != -1) - { - DRD_(cond_set_report_signal_unlocked)(report_signal_unlocked); - } if (shared_threshold_ms != -1) { DRD_(rwlock_set_shared_threshold)(shared_threshold_ms); } - if (segment_merging != -1) - DRD_(thread_set_segment_merging)(segment_merging); if (segment_merge_interval != -1) DRD_(thread_set_segment_merge_interval)(segment_merge_interval); - if (show_confl_seg != -1) - DRD_(set_show_conflicting_segments)(show_confl_seg); if (trace_address) { const Addr addr = VG_(strtoll16)(trace_address, 0); DRD_(start_tracing_address_range)(addr, addr + 1, False); @@ -169,32 +190,6 @@ static Bool DRD_(process_cmd_line_option)(const HChar* arg) length = plus ? VG_(strtoll16)(plus + 1, 0) : 1; DRD_(start_tracing_address_range)(addr, addr + length, True); } - if (trace_barrier != -1) - DRD_(barrier_set_trace)(trace_barrier); - if (trace_clientobj != -1) - DRD_(clientobj_set_trace)(trace_clientobj); - if (trace_cond != -1) - DRD_(cond_set_trace)(trace_cond); - if (trace_csw != -1) - DRD_(thread_trace_context_switches)(trace_csw); - if (trace_fork_join != -1) - DRD_(thread_set_trace_fork_join)(trace_fork_join); - if (trace_hb != -1) - DRD_(hb_set_trace)(trace_hb); - if (trace_conflict_set != -1) - DRD_(thread_trace_conflict_set)(trace_conflict_set); - if (trace_conflict_set_bm != -1) - DRD_(thread_trace_conflict_set_bm)(trace_conflict_set_bm); - if (trace_mutex != -1) - DRD_(mutex_set_trace)(trace_mutex); - if (trace_rwlock != -1) - DRD_(rwlock_set_trace)(trace_rwlock); - if (trace_segment != -1) - DRD_(sg_set_trace)(trace_segment); - if (trace_semaphore != -1) - DRD_(semaphore_set_trace)(trace_semaphore); - if (trace_suppression != -1) - DRD_(suppression_set_trace)(trace_suppression); return True; } diff --git a/include/pub_tool_options.h b/include/pub_tool_options.h index 1879226e80..39c4137349 100644 --- a/include/pub_tool_options.h +++ b/include/pub_tool_options.h @@ -30,6 +30,8 @@ #define __PUB_TOOL_OPTIONS_H #include "pub_tool_basics.h" // for VG_ macro +#include "pub_tool_libcbase.h" // for VG__ str functions +#include "pub_tool_libcprint.h" // for VG_(fmsg_bad_option) #include "libvex.h" // for VexControl // Command line option parsing happens in the following modes: @@ -118,22 +120,47 @@ extern void VG_(list_clo)(const HChar *qq_option); (qq_mode, qq_arg, qq_option, \ VG_STREQ(qq_arg, qq_option))) +static inline +Bool VG_(bool_clom)(Clo_Mode qq_mode, const HChar* qq_arg, const HChar* qq_option, Bool* qq_var, Bool qq_vareq_arg) +{ + Bool res = False; + if (VG_(check_clom)(qq_mode, qq_arg, qq_option, qq_vareq_arg)) + { + const HChar* val = &(qq_arg)[ VG_(strlen)(qq_option)+1 ]; + if (VG_(strcmp)(val, "yes") == 0) + { + *qq_var = True; + res = True; + } + else if (VG_(strcmp)(val, "no") == 0) + { + *qq_var = False; + res = True; + } + else + { + VG_(fmsg_bad_option)(qq_arg, "Invalid boolean value '%s'" + " (should be 'yes' or 'no')\n", + /* gcc 10 (20200119) complains that |val| could be null here. */ + /* I think it is wrong, but anyway, to placate it .. */ + (val ? val : "(null)")); + } + } else if (VG_STREQN(VG_(strlen)(qq_option), qq_arg, qq_option) && + VG_(strlen)(qq_option) == VG_(strlen)(qq_arg)) + { + VG_(fmsg_bad_option)(qq_arg, + "Missing boolean value, did you mean '%s=yes'?\n", + qq_arg); + } + + return res; +} + // String argument, eg. --foo=yes or --foo=no #define VG_BOOL_CLOM(qq_mode, qq_arg, qq_option, qq_var) \ - (VG_(check_clom) \ - (qq_mode, qq_arg, qq_option, \ - VG_STREQN(VG_(strlen)(qq_option)+1, qq_arg, qq_option"=")) && \ - ({Bool res = True; \ - const HChar* val = &(qq_arg)[ VG_(strlen)(qq_option)+1 ]; \ - if VG_STREQ(val, "yes") (qq_var) = True; \ - else if VG_STREQ(val, "no") (qq_var) = False; \ - else {VG_(fmsg_bad_option)(qq_arg, "Invalid boolean value '%s'" \ - " (should be 'yes' or 'no')\n", \ - /* gcc 10 (20200119) complains that |val| could be null here. */ \ - /* I think it is wrong, but anyway, to placate it .. */ \ - (val ? val : "(null)")); \ - res = False; } \ - res; })) + (VG_(bool_clom)((qq_mode), (qq_arg), (qq_option), &(qq_var), \ + VG_STREQN(VG_(strlen)(qq_option)+1, qq_arg, qq_option"=")) \ + ) #define VG_BOOL_CLO(qq_arg, qq_option, qq_var) \ VG_BOOL_CLOM(cloP, qq_arg, qq_option, qq_var) diff --git a/memcheck/mc_main.c b/memcheck/mc_main.c index 979a654097..141cfe19e1 100644 --- a/memcheck/mc_main.c +++ b/memcheck/mc_main.c @@ -6077,7 +6077,7 @@ static const HChar * MC_(parse_leak_heuristics_tokens) = static Bool mc_process_cmd_line_options(const HChar* arg) { const HChar* tmp_str; - Int tmp_show; + Bool tmp_show; tl_assert( MC_(clo_mc_level) >= 1 && MC_(clo_mc_level) <= 3 ); diff --git a/none/tests/Makefile.am b/none/tests/Makefile.am index b3814df638..871ec62777 100644 --- a/none/tests/Makefile.am +++ b/none/tests/Makefile.am @@ -111,6 +111,11 @@ EXTRA_DIST = \ cmdline4.stderr.exp cmdline4.vgtest \ cmdline5.stderr.exp cmdline5.vgtest \ cmdline6.stderr.exp cmdline6.vgtest \ + cmdline7.stderr.exp cmdline7.vgtest \ + cmdline8.stderr.exp cmdline8.vgtest \ + cmdline9.stderr.exp cmdline9.vgtest \ + cmdline10.stderr.exp cmdline10.vgtest \ + cmdline11.stderr.exp cmdline11.vgtest \ cmd-with-special.stderr.exp cmd-with-special.vgtest \ coolo_sigaction.stderr.exp \ coolo_sigaction.stdout.exp coolo_sigaction.vgtest \ diff --git a/none/tests/cmdline10.stderr.exp b/none/tests/cmdline10.stderr.exp new file mode 100644 index 0000000000..38e2917cf2 --- /dev/null +++ b/none/tests/cmdline10.stderr.exp @@ -0,0 +1,3 @@ +valgrind: Bad option: --trace-children=foo +valgrind: Invalid boolean value 'foo' (should be 'yes' or 'no') +valgrind: Use --help for more information or consult the user manual. diff --git a/none/tests/cmdline10.vgtest b/none/tests/cmdline10.vgtest new file mode 100644 index 0000000000..99d04345bd --- /dev/null +++ b/none/tests/cmdline10.vgtest @@ -0,0 +1,3 @@ +# A boolean arg, bad val +prog: ../../tests/true +vgopts: --trace-children=foo diff --git a/none/tests/cmdline11.stderr.exp b/none/tests/cmdline11.stderr.exp new file mode 100644 index 0000000000..ae92ec9ff5 --- /dev/null +++ b/none/tests/cmdline11.stderr.exp @@ -0,0 +1,3 @@ +valgrind: Bad option: --trace-children +valgrind: Missing boolean value, did you mean '--trace-children=yes'? +valgrind: Use --help for more information or consult the user manual. diff --git a/none/tests/cmdline11.vgtest b/none/tests/cmdline11.vgtest new file mode 100644 index 0000000000..2b9e64d8ad --- /dev/null +++ b/none/tests/cmdline11.vgtest @@ -0,0 +1,4 @@ +# A boolean arg no equals or arg +# this one for https://bugs.kde.org/show_bug.cgi?id=351857 +prog: ../../tests/true +vgopts: --trace-children diff --git a/none/tests/cmdline7.stderr.exp b/none/tests/cmdline7.stderr.exp new file mode 100644 index 0000000000..139597f9cb --- /dev/null +++ b/none/tests/cmdline7.stderr.exp @@ -0,0 +1,2 @@ + + diff --git a/none/tests/cmdline7.vgtest b/none/tests/cmdline7.vgtest new file mode 100644 index 0000000000..22691688ed --- /dev/null +++ b/none/tests/cmdline7.vgtest @@ -0,0 +1,3 @@ +# a boolean arg, no +prog: ../../tests/true +vgopts: --trace-children=no diff --git a/none/tests/cmdline8.stderr.exp b/none/tests/cmdline8.stderr.exp new file mode 100644 index 0000000000..139597f9cb --- /dev/null +++ b/none/tests/cmdline8.stderr.exp @@ -0,0 +1,2 @@ + + diff --git a/none/tests/cmdline8.vgtest b/none/tests/cmdline8.vgtest new file mode 100644 index 0000000000..ecbc01fcee --- /dev/null +++ b/none/tests/cmdline8.vgtest @@ -0,0 +1,3 @@ +# a boolean arg, yes +prog: ../../tests/true +vgopts: --trace-children=yes diff --git a/none/tests/cmdline9.stderr.exp b/none/tests/cmdline9.stderr.exp new file mode 100644 index 0000000000..6e965c8dc0 --- /dev/null +++ b/none/tests/cmdline9.stderr.exp @@ -0,0 +1,3 @@ +valgrind: Bad option: --trace-children= +valgrind: Invalid boolean value '' (should be 'yes' or 'no') +valgrind: Use --help for more information or consult the user manual. diff --git a/none/tests/cmdline9.vgtest b/none/tests/cmdline9.vgtest new file mode 100644 index 0000000000..cd4fe56d0b --- /dev/null +++ b/none/tests/cmdline9.vgtest @@ -0,0 +1,3 @@ +# a boolean arg, nothing after = +prog: ../../tests/true +vgopts: --trace-children= |
|
From: Mark W. <ma...@so...> - 2022-11-12 12:06:00
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=ea919973941e5dddc3a9611946b7cc6ca9d87a4f commit ea919973941e5dddc3a9611946b7cc6ca9d87a4f Author: Alexandra Petlanova Hajkova <aha...@re...> Date: Wed Sep 7 05:46:55 2022 -0400 vgdb: allow address reuse to avoid "address already in use" errors https://bugs.kde.org/show_bug.cgi?id=459476 Diff: --- NEWS | 1 + coregrind/vgdb.c | 8 ++++++++ 2 files changed, 9 insertions(+) diff --git a/NEWS b/NEWS index fe94546fbd..a421b980c5 100644 --- a/NEWS +++ b/NEWS @@ -22,6 +22,7 @@ are not entered into bugzilla tend to get forgotten about or ignored. 170510 Don't warn about ioctl of size 0 without direction hint 444110 priv/guest_ppc_toIR.c:36198:31: warning: duplicated 'if' condition. +459476 vgdb: allow address reuse to avoid "address already in use" errorsuse" errors To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX diff --git a/coregrind/vgdb.c b/coregrind/vgdb.c index 3f438536b2..83f49c840d 100644 --- a/coregrind/vgdb.c +++ b/coregrind/vgdb.c @@ -498,6 +498,14 @@ void wait_for_gdb_connect(int in_port) XERROR(errno, "cannot create socket\n"); } + /* allow address reuse to avoid "address already in use" errors */ + + int one = 1; + if (setsockopt(listen_gdb, SOL_SOCKET, SO_REUSEADDR, + &one, sizeof(one)) < 0) { + XERROR(errno, "cannot enable address reuse\n"); + } + memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; |
|
From: Paul F. <pa...@so...> - 2022-11-10 21:33:11
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=f2550057e1e9918c9dfc8fde44db37beac2cc563 commit f2550057e1e9918c9dfc8fde44db37beac2cc563 Author: Paul Floyd <pj...@wa...> Date: Thu Nov 10 22:31:07 2022 +0100 Bug 170510 - Don't warn about ioctl of size 0 without direction hint Apply this to generic and update the message on all platforms. Diff: --- NEWS | 3 ++- coregrind/m_syswrap/syswrap-freebsd.c | 5 ++--- coregrind/m_syswrap/syswrap-generic.c | 4 ++-- none/tests/ioctl_moans.stderr.exp | 20 ++++++++++---------- 4 files changed, 16 insertions(+), 16 deletions(-) diff --git a/NEWS b/NEWS index 208d8afab7..fe94546fbd 100644 --- a/NEWS +++ b/NEWS @@ -20,7 +20,8 @@ bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather than mailing the developers (or mailing lists) directly -- bugs that are not entered into bugzilla tend to get forgotten about or ignored. -444110 priv/guest_ppc_toIR.c:36198:31: warning: duplicated 'if' condition. +170510 Don't warn about ioctl of size 0 without direction hint +444110 priv/guest_ppc_toIR.c:36198:31: warning: duplicated 'if' condition. To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX diff --git a/coregrind/m_syswrap/syswrap-freebsd.c b/coregrind/m_syswrap/syswrap-freebsd.c index 0fad6aa844..0dc76854ef 100644 --- a/coregrind/m_syswrap/syswrap-freebsd.c +++ b/coregrind/m_syswrap/syswrap-freebsd.c @@ -1013,7 +1013,7 @@ PRE(sys_ioctl) * drivers with a large number of strange ioctl * commands becomes very tiresome. */ - } else if ((dir == _VKI_IOC_NONE) && size > 0) { + } else if (dir == _VKI_IOC_NONE && size > 0) { static UWord unknown_ioctl[10]; static Int moans = sizeof(unknown_ioctl) / sizeof(unknown_ioctl[0]); if (moans > 0 && !VG_(clo_xml)) { @@ -1026,11 +1026,10 @@ PRE(sys_ioctl) unknown_ioctl[i] = ARG2; moans--; VG_(umsg)("Warning: noted but unhandled ioctl 0x%lx" - " with no size/direction hints.\n", ARG2); + " with no direction hints.\n", ARG2); VG_(umsg)(" This could cause spurious value errors to appear.\n"); VG_(umsg)(" See README_MISSING_SYSCALL_OR_IOCTL for " "guidance on writing a proper wrapper.\n" ); - //VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size)); return; } } diff --git a/coregrind/m_syswrap/syswrap-generic.c b/coregrind/m_syswrap/syswrap-generic.c index 7d11ff4064..f0796f8ebc 100644 --- a/coregrind/m_syswrap/syswrap-generic.c +++ b/coregrind/m_syswrap/syswrap-generic.c @@ -3795,7 +3795,7 @@ void ML_(PRE_unknown_ioctl)(ThreadId tid, UWord request, UWord arg) * drivers with a large number of strange ioctl * commands becomes very tiresome. */ - } else if (/* size == 0 || */ dir == _VKI_IOC_NONE) { + } else if (dir == _VKI_IOC_NONE && size > 0) { static UWord unknown_ioctl[10]; static Int moans = sizeof(unknown_ioctl) / sizeof(unknown_ioctl[0]); @@ -3809,7 +3809,7 @@ void ML_(PRE_unknown_ioctl)(ThreadId tid, UWord request, UWord arg) unknown_ioctl[i] = request; moans--; VG_(umsg)("Warning: noted but unhandled ioctl 0x%lx" - " with no size/direction hints.\n", request); + " with no direction hints.\n", request); VG_(umsg)(" This could cause spurious value errors to appear.\n"); VG_(umsg)(" See README_MISSING_SYSCALL_OR_IOCTL for " "guidance on writing a proper wrapper.\n" ); diff --git a/none/tests/ioctl_moans.stderr.exp b/none/tests/ioctl_moans.stderr.exp index 2a1ac04ce1..4d7912e4a1 100644 --- a/none/tests/ioctl_moans.stderr.exp +++ b/none/tests/ioctl_moans.stderr.exp @@ -1,30 +1,30 @@ -Warning: noted but unhandled ioctl 0x.2345670 with no size/direction hints. +Warning: noted but unhandled ioctl 0x.2345670 with no direction hints. This could cause spurious value errors to appear. See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. -Warning: noted but unhandled ioctl 0x.2345671 with no size/direction hints. +Warning: noted but unhandled ioctl 0x.2345671 with no direction hints. This could cause spurious value errors to appear. See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. -Warning: noted but unhandled ioctl 0x.2345672 with no size/direction hints. +Warning: noted but unhandled ioctl 0x.2345672 with no direction hints. This could cause spurious value errors to appear. See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. -Warning: noted but unhandled ioctl 0x.2345673 with no size/direction hints. +Warning: noted but unhandled ioctl 0x.2345673 with no direction hints. This could cause spurious value errors to appear. See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. -Warning: noted but unhandled ioctl 0x.2345674 with no size/direction hints. +Warning: noted but unhandled ioctl 0x.2345674 with no direction hints. This could cause spurious value errors to appear. See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. -Warning: noted but unhandled ioctl 0x.2345675 with no size/direction hints. +Warning: noted but unhandled ioctl 0x.2345675 with no direction hints. This could cause spurious value errors to appear. See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. -Warning: noted but unhandled ioctl 0x.2345676 with no size/direction hints. +Warning: noted but unhandled ioctl 0x.2345676 with no direction hints. This could cause spurious value errors to appear. See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. -Warning: noted but unhandled ioctl 0x.2345677 with no size/direction hints. +Warning: noted but unhandled ioctl 0x.2345677 with no direction hints. This could cause spurious value errors to appear. See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. -Warning: noted but unhandled ioctl 0x.2345678 with no size/direction hints. +Warning: noted but unhandled ioctl 0x.2345678 with no direction hints. This could cause spurious value errors to appear. See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. -Warning: noted but unhandled ioctl 0x.2345679 with no size/direction hints. +Warning: noted but unhandled ioctl 0x.2345679 with no direction hints. This could cause spurious value errors to appear. See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. |
|
From: Mahin P. <mah...@ac...> - 2022-11-01 10:33:23
|
Hi John, All
Here is more information of OS & Valgrind on which I am getting below error (pasting error and information in single place) while running Valgrind:
--------------------- Valgrind Error ---------
…
==2214549== Invalid write of size 8
==2214549== at 0x46C0040: setup_raise_exception (signal_x86_64.c:2158)
==2214549== by 0x46C0653: segv_handler (signal_x86_64.c:2626)
==2214549== by 0x407641F: ??? (in /usr/lib/x86_64-linux-gnu/libpthread-2.31.so)
==2214549== Address 0x22fbd0 is in a rw- anonymous segment
…
…
==2214549== valgrind: Unrecognised instruction at address 0x46bc3d9.
==2214549== at 0x46BC3D9: __wine_syscall_dispatcher (in /usr/local/lib/wine/x86_64-unix/ntdll.so)
==2214549== by 0x170055EEF: LdrResolveDelayLoadedAPI (loader.c:3515)
==2214549== Your program just tried to execute an instruction that Valgrind
==2214549== did not recognise. There are two possible reasons for this.
==2214549== 1. Your program has a bug and erroneously jumped to a non-code
==2214549== location. If you are running Memcheck and you just saw a
==2214549== warning about a bad jump, it's probably your program's fault.
==2214549== 2. The instruction is legitimate but Valgrind doesn't handle it,
==2214549== i.e. it's Valgrind's fault. If you think this is the case or
==2214549== you are not sure, please let us know and we'll try to fix it.
==2214549== Either way, Valgrind will now raise a SIGILL signal which will
==2214549== probably kill your program.
0508:err:seh:segv_handler Got unexpected trap 0
…
-------------------------------- Source code -----------
> cat a.c
#include <stdio.h>
#include <stdlib.h>
#include <locale.h>
int main (int argc, char *argv[])
{
FILE *fin;
FILE *fout;
char wc;
fin=fopen("fin","r");
fout=fopen("out.txt","w,ccs=UTF-8");
while((wc=fgetc(fin))!=EOF){
fputc(wc,fout);
printf("%c", wc );
}
fclose(fin);
fclose(fout);
printf("\nFile has been created...%d\n", getpid());
sum(1);
return 0;
}
> cat c.c
void sum(int i)
{
return ;
}
void sum1(int i)
{
return ;
}
-------------- Compilation & run Command ----------------
winegcc -g -o c.o -c c.c
winegcc -g -o a.out a.c c.o
valgrind --trace-children=yes wine64 a.out.so > temp.out 2>&1
-------------------------- Valgrind & OS information -------------
1. Which version of valgrind? Report the output from "valgrind --version".
Where did you get it? If self-built from source then report the git commit hash and date. If pre-built from a software distribution, then report the name and version of the distribution, and the package name and version.
valgrind-3.15.0
valgrind/focal-updates,now 1:3.15.0-1ubuntu9.1 amd64 [installed]
OS: Ubuntu 20.04.2 LTS
2. Which version of Wine lib? Also give the URL for download of the software and installation instructions.
Here is installation instruction : https://wiki.winehq.org/Ubuntu
It's winehq-stable release.
Version: wine-7.0
3. Which execution environment? Report the output from "sed 10q /proc/cpuinfo"
and the VM booting banner from early lines of "dmesg". It really does matter which actual or Virtual Machine.
> sed 10q /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 85
model name : Intel(R) Xeon(R) Gold 6238 CPU @ 2.10GHz
stepping : 7
microcode : 0x500002c
cpu MHz : 2095.078
cache size : 30976 KB
physical id : 0
> dmesg | head -20
[ 0.000000] Linux version 5.4.0-122-generic (buildd@lcy02-amd64-095) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #138-Ubuntu SMP Wed Jun 22 15:00:31 UTC 2022 (Ubuntu 5.4.0-122.138-generic 5.4.192)
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.4.0-122-generic root=/dev/mapper/ubuntu--vg-lv--root ro maybe-ubiquity
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Hygon HygonGenuine
[ 0.000000] Centaur CentaurHauls
[ 0.000000] zhaoxin Shanghai
[ 0.000000] Disabled fast string operations
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x020: 'AVX-512 opmask'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x040: 'AVX-512 Hi256'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x080: 'AVX-512 ZMM_Hi256'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x200: 'Protection Keys User registers'
[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
[ 0.000000] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64
[ 0.000000] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64
[ 0.000000] x86/fpu: xstate_offset[5]: 960, xstate_sizes[5]: 64
[ 0.000000] x86/fpu: xstate_offset[6]: 1024, xstate_sizes[6]: 512
[ 0.000000] x86/fpu: xstate_offset[7]: 1536, xstate_sizes[7]: 1024
[ 0.000000] x86/fpu: xstate_offset[9]: 2560, xstate_sizes[9]: 8
[ 0.000000] x86/fpu: Enabled xstate features 0x2ff, context size is 2568 bytes, using 'compacted' format.
[ 0.000000] BIOS-provided physical RAM map:
4. Which underlying physical hardware (Intel or AMD)? [Perhaps the same as #3.]
> lshw -short
H/W path Device Class Description
================================================
system VMware Virtual Platform
/0 bus 440BX Desktop Reference Platform
/0/0 memory 86KiB BIOS
/0/1 processor Intel(R) Xeon(R) Gold 6238 CPU @ 2.10GHz
/0/1/0 memory 16KiB L1 cache
/0/1/1 memory 16KiB L1 cache
/0/2 processor Intel(R) Xeon(R) Gold 6238 CPU @ 2.10GHz
/0/28 memory 16GiB System Memory
/0/28/0 memory 16GiB DIMM DRAM EDO
/0/28/1 memory DIMM DRAM [empty]
We tried using perf but it is not generating line wise source code profiling eg. time taken by each function calls etc. If any you have some good documentation on perf which can help please suggest.
Is there option I could use Valgrind for profiling source code? Any pointers/suggestion are welcome.
regards,
Mahin
-----Original Message-----
From: John Reiser <jr...@bi...>
Sent: Wednesday, October 19, 2022 3:48 PM
To: val...@li...
Subject: Re: [Valgrind-developers] valgrind: Unrecognised instruction error
On 10/19/22 01:40, Mahin Pandya wrote:
> I am getting below error while running Valgrind, not sure if this is bug in Valgrind, application is build using Wine lib.
>
> Can someone check this?
>
> ---------------------
>
> …
>
> ==2214549== Invalid write of size 8
>
> ==2214549== at 0x46C0040: setup_raise_exception
> (signal_x86_64.c:2158)
>
> ==2214549== by 0x46C0653: segv_handler (signal_x86_64.c:2626)
>
> ==2214549== by 0x407641F: ??? (in
> /usr/lib/x86_64-linux-gnu/libpthread-2.31.so)
>
> ==2214549== Address 0x22fbd0 is in a rw- anonymous segment
[[snip]]
This query is so defective that we'll just ignore it until you fix it.
1. Which version of valgrind? Report the output from "valgrind --version".
Where did you get it? If self-built from source then report the git commit hash and date. If pre-built from a software distribution, then report the name and version of the distribution, and the package name and version.
valgrind-3.15.0
valgrind/focal-updates,now 1:3.15.0-1ubuntu9.1 amd64 [installed]
OS: Ubuntu 20.04.2 LTS
2. Which version of Wine lib? Also give the URL for download of the software and installation instructions.
Here is installation instruction : https://wiki.winehq.org/Ubuntu
It's winehq-stable release.
Version: wine-7.0
3. Which execution environment? Report the output from "sed 10q /proc/cpuinfo"
and the VM booting banner from early lines of "dmesg". It really does matter which actual or Virtual Machine.
> sed 10q /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 85
model name : Intel(R) Xeon(R) Gold 6238 CPU @ 2.10GHz
stepping : 7
microcode : 0x500002c
cpu MHz : 2095.078
cache size : 30976 KB
physical id : 0
> dmesg | head -20
[ 0.000000] Linux version 5.4.0-122-generic (buildd@lcy02-amd64-095) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #138-Ubuntu SMP Wed Jun 22 15:00:31 UTC 2022 (Ubuntu 5.4.0-122.138-generic 5.4.192)
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.4.0-122-generic root=/dev/mapper/ubuntu--vg-lv--root ro maybe-ubiquity
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Hygon HygonGenuine
[ 0.000000] Centaur CentaurHauls
[ 0.000000] zhaoxin Shanghai
[ 0.000000] Disabled fast string operations
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x020: 'AVX-512 opmask'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x040: 'AVX-512 Hi256'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x080: 'AVX-512 ZMM_Hi256'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x200: 'Protection Keys User registers'
[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
[ 0.000000] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64
[ 0.000000] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64
[ 0.000000] x86/fpu: xstate_offset[5]: 960, xstate_sizes[5]: 64
[ 0.000000] x86/fpu: xstate_offset[6]: 1024, xstate_sizes[6]: 512
[ 0.000000] x86/fpu: xstate_offset[7]: 1536, xstate_sizes[7]: 1024
[ 0.000000] x86/fpu: xstate_offset[9]: 2560, xstate_sizes[9]: 8
[ 0.000000] x86/fpu: Enabled xstate features 0x2ff, context size is 2568 bytes, using 'compacted' format.
[ 0.000000] BIOS-provided physical RAM map:
4. Which underlying physical hardware (Intel or AMD)? [Perhaps the same as #3.]
> lshw -short
H/W path Device Class Description
================================================
system VMware Virtual Platform
/0 bus 440BX Desktop Reference Platform
/0/0 memory 86KiB BIOS
/0/1 processor Intel(R) Xeon(R) Gold 6238 CPU @ 2.10GHz
/0/1/0 memory 16KiB L1 cache
/0/1/1 memory 16KiB L1 cache
/0/2 processor Intel(R) Xeon(R) Gold 6238 CPU @ 2.10GHz
/0/28 memory 16GiB System Memory
/0/28/0 memory 16GiB DIMM DRAM EDO
/0/28/1 memory DIMM DRAM [empty]
>
> Is there option I could use Valgrind for profiling source code? Any pointers/suggestion are welcome.
DO NOT start a profiling project using valgrind. Instead, start with 'perf'
which is vastly more capable, flexible, and fast.
_______________________________________________
Valgrind-developers mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Carl L. <ca...@so...> - 2022-10-31 18:29:00
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=873f3766955c4f5caacc014dbe3d4fa0a4f6f712 commit 873f3766955c4f5caacc014dbe3d4fa0a4f6f712 Author: Carl Love <ce...@us...> Date: Mon Oct 31 13:29:31 2022 -0400 Bug 444110 priv/guest_ppc_toIR.c: warning: duplicated 'if' condition The compiler reported a duplicated condition in VEX/priv/guest_ppc_toIR.c The handling of the plbz and xxpermx instructions have the same if/elseif conditions. The else if condition for the plbz instruction was wrong. The elseif statement should be checking for pType2 not pType1. The plbz instruction was inadvertently being handled by the else statement for the lbz instruction. This patch fixes the checking for the plbz and lbz instructions. Diff: --- NEWS | 1 + VEX/priv/guest_ppc_toIR.c | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 614ce44a36..208d8afab7 100644 --- a/NEWS +++ b/NEWS @@ -20,6 +20,7 @@ bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather than mailing the developers (or mailing lists) directly -- bugs that are not entered into bugzilla tend to get forgotten about or ignored. +444110 priv/guest_ppc_toIR.c:36198:31: warning: duplicated 'if' condition. To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX diff --git a/VEX/priv/guest_ppc_toIR.c b/VEX/priv/guest_ppc_toIR.c index 41d7bf65c0..16181768e4 100644 --- a/VEX/priv/guest_ppc_toIR.c +++ b/VEX/priv/guest_ppc_toIR.c @@ -36012,11 +36012,11 @@ DisResult disInstr_PPC_WRK ( // splat instructions: xxpermx if (dis_vector_permute_prefix( prefix, theInstr, abiinfo )) goto decode_success; - } else if (is_prefix && ( ptype == pType1 ) ) { // plbz: load instruction + } else if (is_prefix && ( ptype == pType2 ) ) { // plbz: load instruction if ( !(allow_isa_3_1) ) goto decode_noIsa3_1; if (dis_int_load_prefix( prefix, theInstr )) goto decode_success; - } else { // lbz: load instruction + } else if (!is_prefix) { // lbz: load instruction if (dis_int_load_prefix( prefix, theInstr )) goto decode_success; } |
|
From: Paul F. <pa...@so...> - 2022-10-28 18:20:59
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=6c9aae8f44c50b7949a7a6ed923410eb9c13e9e9 commit 6c9aae8f44c50b7949a7a6ed923410eb9c13e9e9 Author: Paul Floyd <pj...@wa...> Date: Fri Oct 28 22:19:47 2022 +0200 FreeBSD: more filtering for gdbserver_tests/nlvgdbsigqueue Needed for FreeBSD 14 without debug info files. Diff: --- gdbserver_tests/filter_gdb.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gdbserver_tests/filter_gdb.in b/gdbserver_tests/filter_gdb.in index b753e01688..04a56fdef1 100755 --- a/gdbserver_tests/filter_gdb.in +++ b/gdbserver_tests/filter_gdb.in @@ -119,6 +119,7 @@ s/\(0x........\) in ?? ()$/\1 in syscall .../ # return SYSCALL_CANCEL.... s/in __select .*/in syscall .../ s/in __select$/in syscall .../ +s/in _select ()/in syscall .../ /nfds=/d /exceptfds=/d /timeout=/d @@ -135,6 +136,7 @@ s/in \(.__\)\{0,1\}select () from \/.*$/in syscall .../ /^ from \/lib64\/libc.so.*$/d /^ from \/lib64\/.*\/libc.so.*$/d /^ from \/lib64\/.*\/libc-.*.so/d +s/ from \/lib\/libc\.so.*// # and yet another (gdb 7.0 way) to get a system call s/in select ()$/in syscall .../ |
|
From: Paul F. <pa...@so...> - 2022-10-28 15:05:25
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=aed1e501c8cd40be23e57c3ad7b086ddae9a6c66 commit aed1e501c8cd40be23e57c3ad7b086ddae9a6c66 Author: Paul Floyd <pj...@wa...> Date: Fri Oct 28 17:04:26 2022 +0200 FreeBSD: fix a typo in my previous commit for VKI_AT_USRSTACKLIM define. Diff: --- include/vki/vki-freebsd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/vki/vki-freebsd.h b/include/vki/vki-freebsd.h index 7f32c9cf86..72633d471d 100644 --- a/include/vki/vki-freebsd.h +++ b/include/vki/vki-freebsd.h @@ -2517,7 +2517,7 @@ struct vki_ps_strings { #define VKI_AT_KPRELOAD 34 /* added in FreeBSD 14 */ #define VKI_AT_USRSTACKBASE 35 -#define VKI_T_USRSTACKLIM 36 +#define VKI_AT_USRSTACKLIM 36 /* AT_COUNT depends on the FreeBSD version, not currently used */ |
|
From: Paul F. <pa...@so...> - 2022-10-28 14:54:31
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=4ff2185f4590b7850de138270b8a0dfdc3ae6c6b commit 4ff2185f4590b7850de138270b8a0dfdc3ae6c6b Author: Paul Floyd <pj...@wa...> Date: Fri Oct 28 16:52:50 2022 +0200 FreeBSD: remove dependency on elf header and make VKI_ copies of AT defines Also prepare NEWS and configure.ac for 3.21.0 Diff: --- NEWS | 29 +++++++++++ configure.ac | 6 +-- coregrind/m_initimg/initimg-freebsd.c | 92 ++++++++++++++++------------------- include/vki/vki-freebsd.h | 41 ++++++++++++++++ 4 files changed, 116 insertions(+), 52 deletions(-) diff --git a/NEWS b/NEWS index 029161cc67..614ce44a36 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,32 @@ +Release 3.21.0 (?? Apr 2023) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux, +PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux, +MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android, +X86/Solaris, AMD64/Solaris, AMD64/MacOSX 10.12, X86/FreeBSD and +AMD64/FreeBSD. There is also preliminary support for X86/macOS 10.13, +AMD64/macOS 10.13 and nanoMIPS/Linux. + +* ==================== CORE CHANGES =================== + + +* ==================== FIXED BUGS ==================== + +The following bugs have been fixed or resolved. Note that "n-i-bz" +stands for "not in bugzilla" -- that is, a bug that was reported to us +but never got a bugzilla entry. We encourage you to file bugs in +bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather +than mailing the developers (or mailing lists) directly -- bugs that +are not entered into bugzilla tend to get forgotten about or ignored. + + +To see details of a given bug, visit + https://bugs.kde.org/show_bug.cgi?id=XXXXXX +where XXXXXX is the bug number as listed above. + +(3.21.0.RC1: ?? Apr 2023) + Release 3.20.0 (24 Oct 2022) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/configure.ac b/configure.ac index 4a3f3db22d..41047dc2c6 100755 --- a/configure.ac +++ b/configure.ac @@ -15,10 +15,10 @@ # Also set the (expected/last) release date here. # Do not forget to rerun ./autogen.sh m4_define([v_major_ver], [3]) -m4_define([v_minor_ver], [20]) +m4_define([v_minor_ver], [21]) m4_define([v_micro_ver], [0]) -m4_define([v_suffix_ver], []) -m4_define([v_rel_date], ["24 Oct 2022"]) +m4_define([v_suffix_ver], [GIT]) +m4_define([v_rel_date], ["?? Apr 2023"]) m4_define([v_version], m4_if(v_suffix_ver, [], [v_major_ver.v_minor_ver.v_micro_ver], diff --git a/coregrind/m_initimg/initimg-freebsd.c b/coregrind/m_initimg/initimg-freebsd.c index 8188e60d90..ece565e66d 100644 --- a/coregrind/m_initimg/initimg-freebsd.c +++ b/coregrind/m_initimg/initimg-freebsd.c @@ -52,12 +52,6 @@ #include "pub_core_pathscan.h" #include "pub_core_initimg.h" /* self */ -/* --- !!! --- EXTERNAL HEADERS start --- !!! --- */ -/* This is for ELF types etc, and also the AT_ constants. */ -#include <elf.h> -/* --- !!! --- EXTERNAL HEADERS end --- !!! --- */ - - /*====================================================================*/ /*=== Loading the client ===*/ /*====================================================================*/ @@ -439,30 +433,30 @@ Addr setup_client_stack( void* init_sp, /* now, how big is the auxv? */ auxsize = sizeof(*auxv); /* there's always at least one entry: AT_NULL */ - for (cauxv = orig_auxv; cauxv->a_type != AT_NULL; cauxv++) { + for (cauxv = orig_auxv; cauxv->a_type != VKI_AT_NULL; cauxv++) { auxsize += sizeof(*cauxv); switch(cauxv->a_type) { - case AT_EXECPATH: + case VKI_AT_EXECPATH: stringsize += VG_(strlen)(cauxv->u.a_ptr) + 1; break; - case AT_CANARYLEN: + case VKI_AT_CANARYLEN: canarylen = cauxv->u.a_val; /*VG_ROUNDUP(stringsize, sizeof(Word));*/ stringsize += canarylen; break; - case AT_PAGESIZESLEN: + case VKI_AT_PAGESIZESLEN: pagesizeslen = cauxv->u.a_val; /*VG_ROUNDUP(stringsize, sizeof(Word));*/ stringsize += pagesizeslen; break; #if 0 - case AT_TIMEKEEP: + case VKI_AT_TIMEKEEP: /*VG_ROUNDUP(stringsize, sizeof(Word));*/ stringsize += sizeof(struct vki_vdso_timehands); break; #endif #if (FREEBSD_VERS >= FREEBSD_13_0) - case AT_PS_STRINGS: + case VKI_AT_PS_STRINGS: stringsize += sizeof(struct vki_ps_strings); break; #endif @@ -622,7 +616,7 @@ Addr setup_client_stack( void* init_sp, *client_auxv = (UInt *)auxv; VG_(client_auxv) = (UWord *)*client_auxv; - for (; orig_auxv->a_type != AT_NULL; auxv++, orig_auxv++) { + for (; orig_auxv->a_type != VKI_AT_NULL; auxv++, orig_auxv++) { /* copy the entry... */ *auxv = *orig_auxv; @@ -637,49 +631,49 @@ Addr setup_client_stack( void* init_sp, */ switch(auxv->a_type) { - case AT_IGNORE: - case AT_PHENT: - case AT_PAGESZ: - case AT_FLAGS: - case AT_NOTELF: - case AT_UID: - case AT_EUID: - case AT_GID: - case AT_EGID: - case AT_STACKPROT: - case AT_NCPUS: - case AT_OSRELDATE: - case AT_PAGESIZESLEN: - case AT_CANARYLEN: + case VKI_AT_IGNORE: + case VKI_AT_PHENT: + case VKI_AT_PAGESZ: + case VKI_AT_FLAGS: + case VKI_AT_NOTELF: + case VKI_AT_UID: + case VKI_AT_EUID: + case VKI_AT_GID: + case VKI_AT_EGID: + case VKI_AT_STACKPROT: + case VKI_AT_NCPUS: + case VKI_AT_OSRELDATE: + case VKI_AT_PAGESIZESLEN: + case VKI_AT_CANARYLEN: #if (FREEBSD_VERS >= FREEBSD_11) // FreeBSD 11+ also have HWCAP and HWCAP2 - case AT_EHDRFLAGS: + case VKI_AT_EHDRFLAGS: #endif /* All these are pointerless, so we don't need to do anything about them. */ break; - case AT_EXECPATH: + case VKI_AT_EXECPATH: auxv->u.a_ptr = copy_str(&strtab, orig_auxv->u.a_ptr); break; - case AT_CANARY: + case VKI_AT_CANARY: if (canarylen >= 1) auxv->u.a_ptr = copy_bytes(&strtab, orig_auxv->u.a_ptr, canarylen); else - auxv->a_type = AT_IGNORE; + auxv->a_type = VKI_AT_IGNORE; break; - case AT_PAGESIZES: + case VKI_AT_PAGESIZES: if (pagesizeslen >= 1) auxv->u.a_ptr = copy_bytes(&strtab, orig_auxv->u.a_ptr, pagesizeslen); else - auxv->a_type = AT_IGNORE; + auxv->a_type = VKI_AT_IGNORE; break; #if 0 /* * @todo PJF this crashes intermittently */ - case AT_TIMEKEEP: + case VKI_AT_TIMEKEEP: auxv->u.a_ptr = copy_bytes(&strtab, orig_auxv->u.a_ptr, sizeof(struct vki_vdso_timehands)); break; #endif @@ -688,18 +682,18 @@ Addr setup_client_stack( void* init_sp, /* @todo PJF BSDFLAGS causes serveral testcases to crash. Not sure why, it seems to be used for sigfastblock */ // case AT_BSDFLAGS: - case AT_ARGC: - case AT_ENVC: + case VKI_AT_ARGC: + case VKI_AT_ENVC: break; - case AT_PS_STRINGS: + case VKI_AT_PS_STRINGS: auxv->u.a_ptr = copy_bytes(&strtab, orig_auxv->u.a_ptr, sizeof(struct vki_ps_strings)); ((struct vki_ps_strings*)auxv->u.a_ptr)->ps_envstr = (char**)VG_(client_envp); ((struct vki_ps_strings*)auxv->u.a_ptr)->ps_argvstr = (char**)client_argv; break; - case AT_ARGV: + case VKI_AT_ARGV: auxv->u.a_val = client_argv; break; - case AT_ENVV: + case VKI_AT_ENVV: auxv->u.a_val = (Word)VG_(client_envp); break; #endif @@ -714,33 +708,33 @@ Addr setup_client_stack( void* init_sp, #endif #if (FREEBSD_VERS >= FREEBSD_14) - case AT_USRSTACKBASE: + case VKI_AT_USRSTACKBASE: auxv->u.a_val = VG_(get_usrstack)(); break; - case AT_USRSTACKLIM: + case VKI_AT_USRSTACKLIM: auxv->u.a_val = clstack_max_size; break; #endif - case AT_PHDR: + case VKI_AT_PHDR: if (info->phdr == 0) - auxv->a_type = AT_IGNORE; + auxv->a_type = VKI_AT_IGNORE; else auxv->u.a_val = info->phdr; break; - case AT_PHNUM: + case VKI_AT_PHNUM: if (info->phdr == 0) - auxv->a_type = AT_IGNORE; + auxv->a_type = VKI_AT_IGNORE; else auxv->u.a_val = info->phnum; break; - case AT_BASE: + case VKI_AT_BASE: auxv->u.a_val = info->interp_offset; break; - case AT_ENTRY: + case VKI_AT_ENTRY: auxv->u.a_val = info->entry; break; @@ -749,12 +743,12 @@ Addr setup_client_stack( void* init_sp, VG_(debugLog)(2, "initimg", "stomping auxv entry %llu\n", (ULong)auxv->a_type); - auxv->a_type = AT_IGNORE; + auxv->a_type = VKI_AT_IGNORE; break; } } *auxv = *orig_auxv; - vg_assert(auxv->a_type == AT_NULL); + vg_assert(auxv->a_type == VKI_AT_NULL); vg_assert((strtab-stringbase) == stringsize); diff --git a/include/vki/vki-freebsd.h b/include/vki/vki-freebsd.h index c7481f31c7..7f32c9cf86 100644 --- a/include/vki/vki-freebsd.h +++ b/include/vki/vki-freebsd.h @@ -2479,7 +2479,48 @@ struct vki_ps_strings { //---------------------------------------------------------------------- #define VKI_AT_NULL 0 +#define VKI_AT_IGNORE 1 +#define VKI_AT_EXECFD 2 +#define VKI_AT_PHDR 3 +#define VKI_AT_PHENT 4 +#define VKI_AT_PHNUM 5 +#define VKI_AT_PAGESZ 6 +#define VKI_AT_BASE 7 +#define VKI_AT_FLAGS 8 +#define VKI_AT_ENTRY 9 +#define VKI_AT_NOTELF 10 +#define VKI_AT_UID 11 +#define VKI_AT_EUID 12 +#define VKI_AT_GID 13 +#define VKI_AT_EGID 14 +#define VKI_AT_EXECPATH 15 +#define VKI_AT_CANARY 16 +#define VKI_AT_CANARYLEN 17 +#define VKI_AT_OSRELDATE 18 +#define VKI_AT_NCPUS 19 +#define VKI_AT_PAGESIZES 20 +#define VKI_AT_PAGESIZESLEN 21 +#define VKI_AT_TIMEKEEP 22 +#define VKI_AT_STACKPROT 23 +#define VKI_AT_EHDRFLAGS 24 +#define VKI_AT_HWCAP 25 +#define VKI_AT_HWCAP2 26 +/* added in FreeBSD 13 */ +#define VKI_AT_BSDFLAGS 27 +#define VKI_AT_ARGC 28 +#define VKI_AT_ARGV 29 +#define VKI_AT_ENVC 30 +#define VKI_AT_ENVV 31 #define VKI_AT_PS_STRINGS 32 +/* added in FreeBSD 13.1 */ +#define VKI_AT_FXRNG 33 +#define VKI_AT_KPRELOAD 34 +/* added in FreeBSD 14 */ +#define VKI_AT_USRSTACKBASE 35 +#define VKI_T_USRSTACKLIM 36 + +/* AT_COUNT depends on the FreeBSD version, not currently used */ + #define VKI_NT_FREEBSD_ABI_TAG 1 #define VKI_NT_FREEBSD_FEATURE_CTL 4 |
|
From: Feiyang C. <chr...@gm...> - 2022-10-25 07:32:09
|
Hi, The series is now rebased on 3.20.0. Could you review this series? https://bugs.kde.org/show_bug.cgi?id=457504 Thanks, Feiyang |
|
From: Mark W. <ma...@kl...> - 2022-10-24 19:47:10
|
We are pleased to announce a new release of Valgrind, version 3.20.0, available from https://valgrind.org/downloads/current.html. See the release notes below for details of changes. Our thanks to all those who contribute to Valgrind's development. This release represents a great deal of time, energy and effort on the part of many people. Happy and productive debugging and profiling, -- The Valgrind Developers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux, PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux, MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android, X86/Solaris, AMD64/Solaris, AMD64/MacOSX 10.12, X86/FreeBSD and AMD64/FreeBSD. There is also preliminary support for X86/macOS 10.13, AMD64/macOS 10.13 and nanoMIPS/Linux. * ==================== CORE CHANGES =================== * The option "--vgdb-stop-at=event1,event2,..." accepts the new value abexit. This indicates to invoke gdbserver when your program exits abnormally (i.e. with a non zero exit code). * Fix Rust v0 name demangling. * The Linux rseq syscall is now implemented as (silently) returning ENOSYS. * Add FreeBSD syscall wrappers for __specialfd and __realpathat. * Remove FreeBSD dependencies on COMPAT10, which fixes compatibility with HardenedBSD * The option --enable-debuginfod=<no|yes> [default: yes] has been added on Linux. * More DWARF5 support as generated by clang14. * ==================== FIXED BUGS ==================== The following bugs have been fixed or resolved. Note that "n-i-bz" stands for "not in bugzilla" -- that is, a bug that was reported to us but never got a bugzilla entry. We encourage you to file bugs in bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather than mailing the developers (or mailing lists) directly -- bugs that are not entered into bugzilla tend to get forgotten about or ignored. 131186 writev reports error in (vector[...]) 434764 iconv_open causes ld.so v2.28+ to use optimised strncmp 446754 Improve error codes from alloc functions under memcheck 452274 memcheck crashes with Assertion 'sci->status.what == SsIdle' failed 452779 Valgrind fails to build on FreeBSD 13.0 with llvm-devel (15.0.0) 453055 shared_timed_mutex drd test fails with "Lock shared failed" message 453602 Missing command line option to enable/disable debuginfod 452802 Handle lld 9+ split RW PT_LOAD segments correctly 454040 s390x: False-positive memcheck:cond in memmem on arch13 systems 456171 [PATCH] FreeBSD: Don't record address errors when accessing the 'kern.ps_strings' sysctl struct n-i-bz Implement vgdb invoker on FreeBSD 458845 PowerPC: The L field for the dcbf and sync instruction should be 3 bits in ISA 3.1. 458915 Remove register cache to fix 458915 gdbserver causes wrong syscall return 459031 Documentation on --error-exitcode incomplete 459477 XERROR messages lacks ending '\n' in vgdb To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX where XXXXXX is the bug number as listed above. (3.20.0.RC1: 20 Oct 2022) |
|
From: Mark W. <ma...@so...> - 2022-10-24 12:13:16
|
The signed tag 'VALGRIND_3_20_0' was created pointing to:
5147d671e4... -> 3.20.0 final
Tagger: Mark Wielaard <ma...@kl...>
Date: Mon Oct 24 14:12:22 2022 +0200
valgrind 3.20.0 release
|
|
From: Mark W. <ma...@so...> - 2022-10-24 12:00:49
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=5147d671e4cb053ccc5d015cf1322692cc31f20a commit 5147d671e4cb053ccc5d015cf1322692cc31f20a Author: Mark Wielaard <ma...@kl...> Date: Mon Oct 24 13:59:17 2022 +0200 -> 3.20.0 final Diff: --- NEWS | 8 +++++--- configure.ac | 4 ++-- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index c40a0fc70c..029161cc67 100644 --- a/NEWS +++ b/NEWS @@ -1,4 +1,4 @@ -Release 3.20.0 (22 Oct 2022) +Release 3.20.0 (24 Oct 2022) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux, @@ -16,8 +16,10 @@ AMD64/macOS 10.13 and nanoMIPS/Linux. * Fix Rust v0 name demangling. * The Linux rseq syscall is now implemented as (silently) returning ENOSYS. * Add FreeBSD syscall wrappers for __specialfd and __realpathat. -* Remove FreeBSD dependencies on COMPAT10, which fixes compatibility with HardenedBSD -* The option --enable-debuginfod=<no|yes> [default: yes] has been added on Linux. +* Remove FreeBSD dependencies on COMPAT10, which fixes compatibility with + HardenedBSD +* The option --enable-debuginfod=<no|yes> [default: yes] has been added on + Linux. * More DWARF5 support as generated by clang14. * ==================== FIXED BUGS ==================== diff --git a/configure.ac b/configure.ac index 196dc4c573..4a3f3db22d 100755 --- a/configure.ac +++ b/configure.ac @@ -17,8 +17,8 @@ m4_define([v_major_ver], [3]) m4_define([v_minor_ver], [20]) m4_define([v_micro_ver], [0]) -m4_define([v_suffix_ver], [RC1]) -m4_define([v_rel_date], ["20 Oct 2022"]) +m4_define([v_suffix_ver], []) +m4_define([v_rel_date], ["24 Oct 2022"]) m4_define([v_version], m4_if(v_suffix_ver, [], [v_major_ver.v_minor_ver.v_micro_ver], |
|
From: Philippe W. <phi...@sk...> - 2022-10-23 14:19:05
|
On Sun, 2022-10-23 at 00:11 +0200, Mark Wielaard wrote: > Hi Philippe, > > On Sat, Oct 22, 2022 at 02:58:28PM +0200, Philippe Waroquiers wrote: > > I have started running valgrind on valgrind (outer/inner setup). > > Results should be available tomorrow evening or so ... > > For the first few tests, seems ok. > > > > Just one strange thing: > > The outer valgrind crashes on the below test (while the native run of this test is ok). > > (this is on gcc farm gcc186). > > > > Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode, > > but would not be ok when the same valgrind runs as an outer. > > In any case, this is not blocking. > > > > More complete results will follow ... > > Thanks. I have no theory for the outer valgrind crash. But it doesn't > seem blocking indeed. I am also still running some tests. Please let > me know of further results. And do the actual release on Monday > (unless some regression blocker turns up). > > Cheers, > > Mark > For the crash of the outer valgrind: there is in fact some debug info really missing on gcc186 (also for the inner) for the 32 bits version. I have looked at the results of this outer/inner setup and found nothing that seems problematic. Note that analysis the outer logs is always painful, as the outer reports as "bugs" the fact the inner uses e.g. some invalid memory because the guest program run by the inner is designed to test the usage of such invalid memory. Thanks Philippe |
|
From: Paul F. <pj...@wa...> - 2022-10-23 13:36:58
|
On 10/20/22 02:10 PM, Paul Floyd wrote: > > > On 10/20/22 01:52 AM, Mark Wielaard wrote: >> Greetings. >> >> A first release candidate for 3.20.0 is available at >> https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2 >> (md5 = 981b9276536843090700c1268549186e) >> >> Please give it a try on platforms that are important for you. If no >> serious issues are reported, the 3.20.0 final release will happen on >> 22 October. > > Not quite in the "important platform" category > > Solaris 11.3, everything builds but there are problems with DRD and > Helgrind > > Around the time of 3.19 I was getting > > == 791 tests, 18 stderr failures, 3 stdout failures, 1 stderrB > failure, 0 stdoutB failures, 0 post failures == > Git bisect says Bisecting: 0 revisions left to test after this (roughly 0 steps) [7844752299b5472b21fc4df765d4cffdf92c6c3d] Bug 452802 Handle lld 9+ split RW PT_LOAD segments correctly I just pushed a change that fixes this and should only affect Solaris. A+ Paul |
|
From: Paul F. <pa...@so...> - 2022-10-23 13:29:57
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=328ece846310e9c9ffbe3ae1b8f2678b1bcbd353 commit 328ece846310e9c9ffbe3ae1b8f2678b1bcbd353 Author: Paul Floyd <pj...@wa...> Date: Sun Oct 23 15:16:51 2022 +0200 Fix DRD and Helgrind on Solaris. It seems as though Solaris RW sections can also have the execute flag set. Checking for RW and !X was causing the debuginfo reading to fail. That meant that the helgrind and drd preload shared libraries weren't processed, and also the rtld bind function pointers not setup. Without the rtld bind function an assert fires and Helgrind and DRD abort. Diff: --- coregrind/m_debuginfo/readelf.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/coregrind/m_debuginfo/readelf.c b/coregrind/m_debuginfo/readelf.c index 6cf08f666f..56e7d4b6f0 100644 --- a/coregrind/m_debuginfo/readelf.c +++ b/coregrind/m_debuginfo/readelf.c @@ -3682,6 +3682,11 @@ Bool ML_(check_elf_and_get_rw_loads) ( Int fd, const HChar* filename, Int * rw_l #else flag_x = 0; #endif + +#if defined(VGO_solaris) + flag_x = 0; +#endif + vg_assert(ehdr_mioff == 0); // ensured by its initialisation ok = ML_(img_valid)(mimg, ehdr_mioff, sizeof(ehdr_m)); vg_assert(ok); // ML_(is_elf_object_file) should ensure this |
|
From: Mark W. <ma...@kl...> - 2022-10-22 22:11:41
|
Hi Philippe, On Sat, Oct 22, 2022 at 02:58:28PM +0200, Philippe Waroquiers wrote: > I have started running valgrind on valgrind (outer/inner setup). > Results should be available tomorrow evening or so ... > For the first few tests, seems ok. > > Just one strange thing: > The outer valgrind crashes on the below test (while the native run of this test is ok). > (this is on gcc farm gcc186). > > Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode, > but would not be ok when the same valgrind runs as an outer. > In any case, this is not blocking. > > More complete results will follow ... Thanks. I have no theory for the outer valgrind crash. But it doesn't seem blocking indeed. I am also still running some tests. Please let me know of further results. And do the actual release on Monday (unless some regression blocker turns up). Cheers, Mark |