Windows modules.log parsing failure on Linux

[Prasun Ratn]

I collected an offline trace on Windows. I copied it over to Linux and tried to run `-simulator_type view` on it but ran into issues parsing modules.log. I understand that this is not supposed to work at present. Let me know if my understanding is incorrect:

This was the failure:

WARNING: Incorrect module field version -1: attempting to handle legacy format
WARNING: Unable to parse module data: custom field mismatch
ERROR: failed to initialize analyzer: Failed to create analysis tool: Tool failed to initialize: Failed to load binaries: Failed to parse module file

I believe that this is because the Windows modules.log has extra columns for checksum and timestamp

Module Table: version 5, count 60
Columns: id, containing_id, start, end, entry, offset, preferred_base, checksum, timestamp, (custom fields), path

.. unlike Linux where these are not present

Module Table: version 5, count 10
Columns: id, containing_id, start, end, entry, offset, preferred_base, (custom fields), path

I see that the parsing is different on the two platforms:

ext/drcovlib/modules.c:

719 #ifdef WINDOWS
720             if (dr_sscanf(buf, "0x%x, 0x%x, ", &info->mod[i].checksum,
721                           &info->mod[i].timestamp) != 2)
722                 goto read_error;
723             buf = skip_commas_and_spaces(buf, 2);
724             if (buf == NULL)
725                 goto read_error;
726 #endif

[Prasun Ratn]

I guess the more fundamental question is if we can even parse Windows exes/dlls on Linux?

--
You received this message because you are subscribed to a topic in the Google Groups "DynamoRIO Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dynamorio-users/VbZ8CMV-e7M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/88c29278-1477-4bd0-8ed9-f39b11516cb1n%40googlegroups.com.

[Derek Bruening]

Today there is no such support.  It could be added: in addition to leveraging existing Windows code inside DR, we'd have to write new code to do the individual segment mappings, which is all done by the kernel on Windows, unlike UNIX.

File an issue?

You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/CAF6hzxy%3DodO4wzmrDekUYBSy484VjHe4zjzBxtH1MJfT2TYzAw%40mail.gmail.com.

[Prasun Ratn]

Have you guys considered adding the instruction opcode bytes to the trace itself - perhaps add a record next to the PC memref(maybe during raw2trace)?. Then the trace would be self-contained.

By the way, the cmd listed in the documentation did not work for me.

**********************************************************************

** Visual Studio 2019 Developer Command Prompt v16.11.7

** Copyright (c) 2021 Microsoft Corporation

**********************************************************************

[vcvarsall.bat] Environment initialized for: 'x64'

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community>

>cmake -G"Visual Studio 16 Win64" ..\dynamorio

CMake Error: Could not create named generator Visual Studio 16 Win64

Instead the following cmd did work:

cmake -G"Visual Studio 16" -A x64 ..\dynamorio

I had to do a 64 bit build because cmake could not find the assembler with the 32-bit build (I guess the masm was missing for some reason). Is 32-bit the recommended build (the wording on https://dynamorio.org/page_building.html#autotoc_md75 suggests this)?

[Derek Bruening]

On Mon, Jun 6, 2022 at 7:45 AM Prasun Ratn <prasu...@gmail.com> wrote:

Have you guys considered adding the instruction opcode bytes to the trace itself - perhaps add a record next to the PC memref(maybe during raw2trace)?. Then the trace would be self-contained.

Yes, that is a proposal on the table.  JIT support requires something like that.  https://github.com/DynamoRIO/dynamorio/issues/5520 covers this.

 

By the way, the cmd listed in the documentation did not work for me.

**********************************************************************

** Visual Studio 2019 Developer Command Prompt v16.11.7

** Copyright (c) 2021 Microsoft Corporation

**********************************************************************

[vcvarsall.bat] Environment initialized for: 'x64'

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community>

>cmake -G"Visual Studio 16 Win64" ..\dynamorio

CMake Error: Could not create named generator Visual Studio 16 Win64

Instead the following cmd did work:

cmake -G"Visual Studio 16" -A x64 ..\dynamorio

Only recently was the VS used updated to 2019 and probably the docs were not updated.  Maybe you could send a PR to update the docs?

 

I had to do a 64 bit build because cmake could not find the assembler with the 32-bit build (I guess the masm was missing for some reason). Is 32-bit the recommended build (the wording on https://dynamorio.org/page_building.html#autotoc_md75 suggests this)?

No, I would do 64-bit over 32-bit, but both should work.