|
From: Tom H. <tom...@so...> - 2019-03-14 15:19:44
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=09566120e705d8831aaa7076b439d3ad90b78773 commit 09566120e705d8831aaa7076b439d3ad90b78773 Author: Tom Hughes <to...@co...> Date: Thu Mar 14 15:15:41 2019 +0000 Suppress FSGSBASE flag from cpuid results We don't support {rd,wr}{fs,gs}base so we shouldn't say we do. Diff: --- VEX/priv/guest_amd64_helpers.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/VEX/priv/guest_amd64_helpers.c b/VEX/priv/guest_amd64_helpers.c index 30e82db..f12b71e 100644 --- a/VEX/priv/guest_amd64_helpers.c +++ b/VEX/priv/guest_amd64_helpers.c @@ -3361,7 +3361,8 @@ void amd64g_dirtyhelper_CPUID_avx2 ( VexGuestAMD64State* st ) break; case 0x00000007: switch (old_ecx) { - case 0x00000000: SET_ABCD(0x00000000, 0x000027ab, + /* Don't advertise FSGSBASE support, bit 0 in EBX. */ + case 0x00000000: SET_ABCD(0x00000000, 0x000027aa, 0x00000000, 0x00000000); break; default: SET_ABCD(0x00000000, 0x00000000, 0x00000000, 0x00000000); break; |
|
From: Ed M. <em...@fr...> - 2019-03-14 18:17:03
|
On Thu, 14 Mar 2019 at 11:20, Tom Hughes <tom...@so...> wrote:
>
> commit 09566120e705d8831aaa7076b439d3ad90b78773
> Author: Tom Hughes <to...@co...>
> Date: Thu Mar 14 15:15:41 2019 +0000
>
> Suppress FSGSBASE flag from cpuid results
>
> We don't support {rd,wr}{fs,gs}base so we shouldn't say we do.
Thanks, I have rebased the FreeBSD patch set on master now and the
test results are consistent with earlier runs.
|
|
From: Paul F. <pj...@wa...> - 2020-02-07 15:57:25
|
> On 14 Mar 2019, at 19:16, Ed Maste <em...@fr...> wrote:
>
> On Thu, 14 Mar 2019 at 11:20, Tom Hughes <tom...@so...> wrote:
>>
>> commit 09566120e705d8831aaa7076b439d3ad90b78773
>> Author: Tom Hughes <to...@co...>
>> Date: Thu Mar 14 15:15:41 2019 +0000
>>
>> Suppress FSGSBASE flag from cpuid results
>>
>> We don't support {rd,wr}{fs,gs}base so we shouldn't say we do.
>
> Thanks, I have rebased the FreeBSD patch set on master now and the
> test results are consistent with earlier runs.
>
Hi
Since I have a bit of free time on my hands (one more week in theory), I’ve also been looking at the FreeBSD port of Valgrind.
Has any work been done on this since last March?
I now have FreeBSD 12.1 reinstalled with Phil Longstaff’s work plus a few of my changes. It seems to work at least for trivial tests - I haven’t yet tried running the regression tests.
At the moment there are 4 things that I see that I need to do
1. Rebase everything onto the main Valgrind development branch
2. I’ve noticed that there is a big issue with clang compiled executables. The problem is that the binaries have 3 PT_LOAD sections (ro, rx, rw) while GCC (and clang on Linux) only generates 2 (rw and rx). This is causing symtab loading to fail. This limits the usefulness somewhat.
3. There were a lot of syscall changes in FreeBSD 12, so I think that ‘configure’ needs to handle/define a freebsd_version variable.
4. There are still quite a few missing syscalls.
A+
Paul
|
|
From: Paul F. <pj...@wa...> - 2020-02-08 19:43:49
|
> On 7 Feb 2020, at 16:57, Paul Floyd <pj...@wa...> wrote:
>
>
>
>> On 14 Mar 2019, at 19:16, Ed Maste <em...@fr...> wrote:
>>
>> On Thu, 14 Mar 2019 at 11:20, Tom Hughes <tom...@so...> wrote:
>>>
>>> commit 09566120e705d8831aaa7076b439d3ad90b78773
>>> Author: Tom Hughes <to...@co...>
>>> Date: Thu Mar 14 15:15:41 2019 +0000
>>>
>>> Suppress FSGSBASE flag from cpuid results
>>>
>>> We don't support {rd,wr}{fs,gs}base so we shouldn't say we do.
>>
>> Thanks, I have rebased the FreeBSD patch set on master now and the
>> test results are consistent with earlier runs.
>>
>
>
> Hi
>
> Since I have a bit of free time on my hands (one more week in theory), I’ve also been looking at the FreeBSD port of Valgrind.
>
> Has any work been done on this since last March?
>
> I now have FreeBSD 12.1 reinstalled with Phil Longstaff’s work plus a few of my changes. It seems to work at least for trivial tests - I haven’t yet tried running the regression tests.
>
> At the moment there are 4 things that I see that I need to do
>
> 1. Rebase everything onto the main Valgrind development branch
> 2. I’ve noticed that there is a big issue with clang compiled executables. The problem is that the binaries have 3 PT_LOAD sections (ro, rx, rw) while GCC (and clang on Linux) only generates 2 (rw and rx). This is causing symtab loading to fail. This limits the usefulness somewhat.
> 3. There were a lot of syscall changes in FreeBSD 12, so I think that ‘configure’ needs to handle/define a freebsd_version variable.
> 4. There are still quite a few missing syscalls.
An update on this
1. I’ve done the rebase. That was fun. Looks like most of the regtests are failing though, and there seems to be an issue with reading semaphores.
2. I’m still seeing this problem, though I’ve seen that Mark Wielaard made a change that should that looks like it should fix this. I’ll look at that next.
3 and 4. No progress yet.
A+
Paul
|
|
From: Paul F. <pj...@wa...> - 2020-02-10 20:36:00
|
Hi The main problem that I have at the moment is that readelf and co aren't redirecting any allocation functions like malloc and free. I cranked up the tracing (4x -v and 4x -d, --trace=symtab=yes). For libc I see (this is just a tiny extract) ------ start ELF OBJECT ------------------------------------------------------- ------ name = /lib/libc.so.7 --48619-- object doesn't have a symbol table --- Reading (ELF, standard) dynamic symbol table (3158 entries) --- raw symbol [ 971]: WEA FUN : svma 0x000011e990, sz 3662 malloc rec(t) [ 971]: val 0x0004ead990, sz 3662 malloc And for libc++ I see ------ start ELF OBJECT ------------------------------------------------------- ------ name = /usr/home/paulf/tools/clang/lib/libc++.so.1.0 --- Reading (ELF, standard) symbol table (3163 entries) --- raw symbol [1179]: WEA FUN : svma 0x00000a7400, sz 116 _Znwm rec(t) [1179]: val 0x0004cfa400, sz 116 _Znwm I'll try the same thing on Linux to try to see where FreeBSD is losing the plot Can anyone suggest where to look for redirection problems? A+ Paul |
|
From: Paul F. <pj...@wa...> - 2020-02-15 08:00:50
|
> On 10 Feb 2020, at 21:35, Paul FLOYD <pj...@wa...> wrote: > > Hi > > The main problem that I have at the moment is that readelf and co aren't redirecting any allocation functions like malloc and free. > OK, after some quite lengthy debugging I’m starting to see what is happening. Here’s my understanding of what is going on. When an executable file gets mmaped this will trigger calls to VG_(redirects_notify_new_DebugInfo) and generate_and_add_actives. The Specs that get read get added to the head of topSpecs and DebugInfos get added to the head of debugInfo_list. vgpreload_memcheck gets loaded first, so that the function/so patterns are added to topSpecs. Then when libc.so/libstdc++.so are loaded, the soname and function names match and the Active gets inserted into activeSet. This is the basis for redirection later. Winding back a bit, in di_notify_ACHIEVE_ACCEPT_STATE there is a call to discard_DebugInfos_which_overlap_with. This is where things are going wrong on FreeBSD. On Linux, the DebugInfos do not overlap, except when comparing a di with itself, for which there is a check and the flag gets cleared. On FreeBSD I’m seeing overlaps - there are repeated values of avma/size. These are for ro DebugInfoMappings. If I add a check that both mappings are not ro then at least for my trivial examples things seem to be working. A+ Paul |
|
From: Paul F. <pj...@wa...> - 2020-02-15 13:07:43
|
Only on amd64 atm == 641 tests, 186 stderr failures, 17 stdout failures, 8 stderrB failures, 14 stdoutB failures, 2 post failures == Much better than I expected. There were 4 or 5 hangs in pipe reads. A+ Paul |