- 24 Nov, 2021 14 commits
-
-
Alexandre Julliard authored
Signed-off-by:Alexandre Julliard <julliard@winehq.org>
-
Alexandre Julliard authored
This has been broken at least since 19549d11. Signed-off-by:
-
Paul Gofman authored
Signed-off-by:
Paul Gofman <pgofman@codeweavers.com> Signed-off-by:
-
Zebediah Figura authored
Signed-off-by:
Zebediah Figura <zfigura@codeweavers.com> Signed-off-by:
Henri Verbeet <hverbeet@codeweavers.com> Signed-off-by:
-
Henri Verbeet authored
Fixes: c2f0ae50Signed-off-by:
-
Henri Verbeet authored
Signed-off-by:
-
Zebediah Figura authored
That is, load Wine system dependencies only when they are imported from Wine builtins or other system dependencies, and do not match a Wine system dependency by its base name when looking for already-loaded modules. The reasoning is that it is possible for an application to ship, and expect to use, a newer version of a MinGW-compiled library, or one with custom patches, or possibly an unrelated library with the same name. We don't want to offer Wine's system dependencies in place of the application's, or vice versa. Signed-off-by:
-
Zebediah Figura authored
Many distributions provide MinGW-compiled system DLLs which are currently bundled with Wine. Unfortunately, while MinGW pkg-config can be used to detect the linking path, there is no standardized runtime path, and many distributions in fact use different paths. Signed-off-by:
-
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Connor McAdams authored
Signed-off-by:
Connor McAdams <cmcadams@codeweavers.com> Signed-off-by:
-
Connor McAdams authored
Signed-off-by:
-
Thomas Faber authored
Signed-off-by:
Thomas Faber <thomas.faber@reactos.org> Signed-off-by:
-
- 23 Nov, 2021 26 commits
-
-
Esme Povirk authored
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51989Signed-off-by:
Esme Povirk <esme@codeweavers.com> Signed-off-by:
-
Georg Lehmann authored
Signed-off-by:
Georg Lehmann <dadschoorse@gmail.com> Signed-off-by:
-
Daniel Lehman authored
Fixes loading XML from a UNC path. Signed-off-by:
Daniel Lehman <dlehman@esri.com> Signed-off-by:
-
Jinoh Kang authored
Today, when gdbproxy is started with --no-start mode, GDB fails to recognise the symbol file unless the `file` command or the `sharedlibrary` command is explicitly issued. Also, RHEL's downstream GDB complains with the following message: Remote gdbserver does not support determining executable automatically. RHEL <=6.8 and <=7.2 versions of gdbserver do not support such automatic executable detection. The following versions of gdbserver support it: - Upstream version of gdbserver (unsupported) 7.10 or later - Red Hat Developer Toolset (DTS) version of gdbserver from DTS 4.0 or later (only on x86_64) - RHEL-7.3 versions of gdbserver (on any architecture) Fix this by implementing the qXfer object "exec-file". Signed-off-by:
Jinoh Kang <jinoh.kang.kr@gmail.com> Signed-off-by:
Rémi Bernon <rbernon@codeweavers.com> Signed-off-by:
-
Jinoh Kang authored
GDB does not retrieve the result of a qXfer command at once; instead, it issues a series of requests to obtain the result one "chunk" at a time, and concatenates those chunks internally. Each request contains offset and length variables that specify which portion of the result shall be retrieved. Today, Winedbg handles this by generating the entire result data each time a request is received and slicing out the requested range for the response. This is not only inefficient due to repeated computation, but also prone to race condition since the result may change between successive chunk requests due to the dynamic nature of some commands such as "libraries" and "threads." Fix this by cacheing the result into a buffer at the first request, and use the buffer to serve successive chunk requests. The cache is invalidated when the remote requests a different object, or the debugger reaches the end of the result cache buffer. Signed-off-by:
-
Jinoh Kang authored
Define a handler lookup table for qXfer commands and use it. This facilitates implementing more qXfer commands and cacheing reply data. Signed-off-by:
-
Jinoh Kang authored
Some dynamic strings (e.g. loaded image paths) may contain XML special characters which breaks parsing. Fix this by escaping all dynamic strings (i.e. character data and attribute values) that go into the XML replies. Signed-off-by:
-
Jinoh Kang authored
Today, gdbproxy reuses the same buffer for both the qXfer reply and the actual GDB packet reply. This worked well, since each byte in the qXfer reply buffer matched 1:1 to each byte in the actual GDB reply packet. Since we escape special characters now, this property no longer holds and a single byte in qXfer reply will take up to two bytes in the GDB reply packet. This causes offsets to shift, preventing the offset/length response slicing (part of GDB protocol) from working correctly. Fix this by writing the qXfer reply data in a separate buffer, and performing slicing out of it. Signed-off-by:
-
Jinoh Kang authored
Signed-off-by:
-
Jinoh Kang authored
This is required for a subsequent patch that adds buffering for GDB qXfer reply data. Signed-off-by:
-
Byeongsik Jeon authored
Signed-off-by:
Byeongsik Jeon <bsjeon@hanmail.net> Signed-off-by:
-
Chilung Chan authored
Signed-off-by:
Chilung Chan <eason066@gmail.com> Signed-off-by:
Jactry Zeng <jzeng@codeweavers.com> Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com> Signed-off-by:
Matteo Bruni <mbruni@codeweavers.com> Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
Huw Davies <huw@codeweavers.com> Signed-off-by:
Andrew Eikum <aeikum@codeweavers.com> Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Eventually everything that calls this will reside in the unixlib. Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
