| Age | Commit message (Collapse) | Author |
|---|
|
* Switched password to placeholder.
* Update MSSqlTestBed.cs
|
|
* [tests] Add BStr and VARIANT in structs interop tests
* [marshal] Fix reverse P/Invoke marshaling VARIANT fields
Partial revert of https://github.com/mono/mono/pull/8732
If a managed struct is declared as
public struct StructWithVariant
{
[MarshalAs (UnmanagedType.Struct)]
public object data;
};
Then the `data` field should be marshalled as a VARIANT.
The fix checks that the field's type is `object` and uses VARIANT for
marshaling, otherwise it continues as in mono/mono#8732 and uses
MONO_MARSHAL_CONV_OBJECT_STRUCT
|
|
|
|
(#20863)
* Allow sending intermediate certificates when authenticating as server
When using SslStream.AuthenticateAsServer, the incoming certificate will be an X509Certificate(2). It will never have the "intermediate" certificates attached. The chain of intermediate certificates needs to be rebuilt on the fly.
* Fix missing "using".
* Update MonoBtlsContext.cs
* Fix indentation and whitespace
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
|
|
offsets-tool can run before mono-dtrace.h is generated which leads to a compiler error about the file missing.
|
|
* CredScan issue - remove hardcoded password
Remove commented out lines of code which had a hardcoded password flagged by the CredScan tool (line 86)
* update net_4_)/web.config file
* update net_1_1\machine.config
* update net_4_5/web.config
* update net_2_0/web.config
|
|
|
|
* Update password
* Revert change for one file
* Update password round 2
* Update more password
|
|
|
|
|
|
|
|
|
|
|
|
This PR implements changes that lets us build Xamarin.iOS/Xamarin.Mac SDKs so that it is possible for a Xamarin.Mac project to target x86_64+arm64 (i.e. Apple Silicon). Most of the changes are related to the mac Sdk build, but there are some extra changes as well :
- Fix configure to not automatically target iOS when targeting aarch64
- Necessary to compile a cross-compiler targetting macOS arm64
- Fix aot compiler to target macOS arm64 when running on x64 (missing arch parameters)
- Support offset tool for aarch64
- Necessary to compile macOS arm64 cross-compiler
- Fix pthread_jit_write_protect_np and preadv usage
- Missing define meant the function wasn't found (at least on Xcode 12.2)
- Restrict usage to macOS
- Fix crash on launch on iOS/tvOS arm64 caused by invalidly setting `MAP_JIT` on those platforms even though it's not a valid option.
- Adapt macOS SDK
- Build libraries for x64+arm64 and lipo them together
- Create a aarch64 cross-compiler for macOS, similar to the iOS Sdk
The arm64 support will only work with Xcode 12.2. To support in Xamarin.Mac, it also doesn't work if built from stable branches (because the rest of the arm64 support hasn't made it to the latest stable branch from what I can figure out)
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
|
|
See https://github.com/mono/mono/issues/20905
|
|
|
|
* [sdb] Add Module.ApplyChanges
* [mini] Add CMD_MODULE_APPLY_CHANGES
Unused, but reserved to keep the protocol enums in sync with dotnet/runtime
* Exclude Mono.Debugger.Soft.dll from apidiff check
* Bump api-snapshot submodule
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
|
|
|
|
|
|
* Check if ContentType was passed on http request.
* Process PATCH http verb.
Co-authored-by: Rodrigo Cesar <rodrigo@fullgauge.com.br>
|
|
* Add an ARMv7 lane, which runs on our AARCH64 pool
* Increase ARMv7 timeout to 3 hours. It doesn't quite finish in 2.
* Update Docker image (now with added ping)
|
|
This allows us to remove a lot of cruft and simplifies our CI build.
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
|
|
It's handled differently now.
(cherry picked from commit a8f265550b3b7fb82dd923fd47279248e6008eb3)
|
|
|
|
Also template-ify it a bit.
|
|
- Fixes some lack of casting warnings
- Fix formatting
- Sometimes a trampoline may be more than 4GB away from its target. We need to detect this and use a load/branch rather than a jump relative
- Implement `mono_arch_patch_code_new` in lieu of `mono_arch_patch_code`
|
|
(#20832)
This change is released under the MIT license.
On a CEE_MONO_ICALL set to mono_threads_detach_coop (from native to managed),
the profile code is always emitted without a return value, since it's not at
a ret. This means it's never set, even if there actually is a return type
(other than TYPE_VOID). When tracing, it's assumed that valid result types
other than TYPE_VOID can be dereferenced, even though in this case no result
has been set. This causes a null dereference fault.
|
|
This password was picked up by credscan. It gives the default password of a database, but I can't find any script that actually uses that default password. It seems like we may as well just remove it.
|
|
Initial AzDO pipeline for basic CI. Ref. https://github.com/mono/mono/issues/20841
|
|
properly (#20845)
|
|
|
|
## Further s390x Fixes
This set up patches enables s390x to pass more of the test suite.
### 1. Mono array layout
The array "raw data" layout is defined in two places, one for the Mono C++ code, and one for C# code (which should match!):
```
struct _MonoArray {
MonoObject obj;
/* bounds is NULL for szarrays */
MonoArrayBounds *bounds;
/* total number of elements of the array */
mono_array_size_t max_length;
/* we use mono_64bitaligned_t to ensure proper alignment on platforms that need it */
mono_64bitaligned_t vector [MONO_ZERO_LEN_ARRAY];
};
```
vs.
```
private class RawData
{
public IntPtr Bounds;
public IntPtr Count;
public byte Data;
}
```
However, this only actually matches perfectly on 32-bit platforms if `MONO_BIG_ARRAYS` is false and 64-bit platforms if `MONO_BIG_ARRAYS` is true. In the dotnet build, `MONO_BIG_ARRAYS` is false, so we have a problem on 64-bit platforms. On little-endian 64-bit platforms the mismatch is mostly harmless, but on big-endian 64-bit platforms this causes test case failures in `System.Tests.ArrayTests.Clear_Invalid`.
The patch fixes this for s390x, but it should be possible to implement this in a cleaner way ...
### 2. Tail call implementation
There were actually two bugs here. First of all, the `tailcall_reg` instruction was not marked in `cpu-s390x.md` to have an sreg1 input, which meant that the target address was never actually loaded up.
More problematically, the way the tailcall implementation handles call-saved argument registers was fundamentally broken. This is a problem on s390x with the r6 register, which is call-saved even though it is also used as argument register. This is a problem for tail calls, because you have to restore the old value before performing the tail call, which conflicts with loading the required argument value. The same problem also applies for the RGCTX/IMT register, which is likewise both call-saved and used to hold an _implicit_ argument.
The current Mono code simply does not restore the old value and only loads the argument value. But that is an ABI break and may cause failures in a caller higher up on the stack once the tail-called routine finally returns. Consider three functions A, B, C where
#### A:
```
[...]
define R6
call B (does not use R6 as argument)
use R6
[...]
```
##### B:
```
save R6
[...]
load R6 with argument value
tail call C (uses R6 as argument)
```
#### C:
```
save R6
[...]
use R6 argument value
[...]
restore R6
return
```
Once C finally returns to A, the value in R6 will be the value it had on entry to C, not that on entry to B, which is what the code in A relies on.
The following patch fixes this by disabling tail calls in those cases where R6 is used as argument register, as well as in all cases where the RGCTX/IMT register is used.
Note that it might be possible to re-enable the latter cases by using a call-clobbered register as RGCTX/IMT register. One option might be `%r1`, which is also used by GCC as the static chain pointer for nested functions (which is a somewhat similar purpose). This would also match what x86_64 is doing: they likewise use the static chain register for RGCTX/IMT.
I haven't implemented this since there might be a problem with other intervening trampolines clobbering %r1 -- this would need careful review and possibly some reshuffling. I guess this can be done later as an optimization.
### 3. Crashes due to corrupted sigaltstack
When sigaltstack is enabled, the kernel provides the address of the alternate stack to signal handlers in the `uc_stack.ss_sp` field. More importantly, the kernel also *reads* out that field once the signal handler returns and updates its notion of what alternate stack is to be used for future signals! This is a problem with current Mono code, which writes the user-code stack pointer into `ss_sp` -- causing the kernel to attempt to use that part of the user stack as alternate stack for the next signal. If that then overlaps then regular stack (which is likely), the kernel will consider this value corrupted and deliver a SIGSEGV instead.
Looking into this, I'm not really sure why Mono (the s390x code only) even writes to `ss_sp` in the first place. This is apparently read out in just one place, where we actually want to know the user stack, so I guess we can just use r15 directly instead.
#### 4. Codegen problem with floating-point to integer conversions
The Mono back-end uses `cegbr`/`cdgbr` (64-bit int to float conversion instructions) even in the case where the source is actually a 32-bit integer. It really should be using `cefbr`/`cdfbr` in those cases, which is what the following patch implements.
Note that I'm a bit unclear about the intention of the original code here: there appears to be some effort made to hold 32-bit integers in 64-bit sign-extended form in registers, in which case the `cegbr`/`cdgbr` would probably be also correct (but still not really preferable). However, this doesn't seem to be done consistently.
#### 5. Codegen problems with integer overflow detection
There were two separate bugs with properly detecting integer overflows. First of all, the `OP_IADD_OVF_UN` implementation used the 64-bit `algr` instead of the 32-bit `alr` instruction. While the (32-bit) numerical result is of course the same, the detected overflow is incorrect.
More problematic is the overflow detection for signed multiplication. The code seems to only verify whether the sign of the result matches the product of the signs of the inputs -- but this doesn't reliably detect overflow! While of course there must have been an overflow if the sign doesn't match, there can still be an overflow if the sign *does* match, for example in the case from the test suite: 1.000.000.000 * 10
Now, on recent machines we have hardware support to detect overflow: `msgrkc` and `msrkc`. While Mono was already using `msgrkc` (so the problem doesn't occur for 64-bit multiplication) it didn't use `msrkc`. The following patch just adds that case. Note that this still only fixes the problem on z14 on higher; the code for older machines really also ought to be fixed at some point.
#### 6. Codegen problems with interlocked add
Finally, there is a subtle problem with the code currently generated for the interlocked add primitives, if the machine supports the laa(g) instruction. Those handle the whole interlocked-add operation in hardware, so the only thing Mono codegen needs to handle in addition is the proper return value. The laa(g) instructions return the value the memory location had *before* the addition, while the Mono interlocked-add primitive is specified to return the value the memory location has *after* the addition.
To fix this discrepancy, the code generated by Mono will perform another load from the memory location immediately after the laa(g). This usually returns the correct value, but it creates a race condition: in between the laa(g) and the load, another thread might have changed the value! This violates the atomicity guarantee of the interlocked-add primitive.
To fix this, the following patch instead uses the (atomically loaded) result of the laa(g) instruction and then simply performs the original addition a second time in registers.
|
|
|
|
|
|
This reverts commit 4f80b7c8e92cf3e4d5cb30749c44397620f849a1.
It's no longer needed now that 9a7219d3be5c595623c7b0e69b9c12312b9c4c1d was reverted.
|
|
* [System.Drawing] Work around libgdiplus Metafile dispose ordering
* Bump API snapshot submodule
Co-authored-by: monojenkins <jo.shields+jenkins@xamarin.com>
|
|
The previous logic would not call `mono_gc_thread_detach` for a number of scenarios. One example:
```
start_wrapper
- mono_thread_info_attach - thread is now live in mono threads layer
- start_wrapper_internal
-- mono_thread_attach_internal - mono attached to vm thread layer. GC handle is set via mono_thread_info_set_internal_thread_gchandle
-- mono_thread_detach_internal - detached from vm thread layer. GC handle cleared via call to mono_thread_info_unset_internal_thread_gchandle
- mono_thread_info_exit
-- mono_thread_info_detach
--- unregister_thread
---- thread_detach callback - checks if gc handle is valid and returns if not via mono_thread_info_try_get_internal_thread_gchandle. We've already cleared above so we never call mono_gc_thread_detach.
```
This change ensures `mono_gc_thread_detach` is always called even the GC handle for the thread has already been cleared.
Co-authored-by: joncham <joncham@users.noreply.github.com>
|
|
This reverts commit 8e82ce21b607f57f2f4889c81edd9c9813530a3f.
|
|
This reverts commit 58542a47f37f5a6ca8c5227b7fd55e5e0881658f.
|
|
This reverts commit f658376029e61fbb1978e8f8286f37ffbba2a0cb.
|
|
All of the flagged instances are harmless
|
|
|
|
* Fix the c++ build.
* Remove some unused prototypes.
* Initial arm64e support.
|
|
Context: https://github.com/android/ndk/wiki/Changelog-r22#announcements
Context: https://github.com/xamarin/xamarin-android/pull/5475
This commit fixes a problem where the AOT compiler hard-codes the native
linker executable name to a platform-specific value but such an
executable does not exist in the toolchain being used, thus making the
AOT compiler fail to link the final binary.
The specific use case here is the new Android NDK r22 which not only
deprecates GNU binutils, but also removes architecture-prefixed `ld`
binary (e.g. `aarch64-linux-android-ld` no longer exists). Instead, the
NDK provides a non-prefixed `ld` binary and two prefixed ones:
`$arch-ld.gold` and `$arch-ld.bfd`. However, since the AOT compiler
hardcodes `ld` as the linker name on Linux systems, the AOT compilation
fails when attempting to link the final executable. Which, in turn,
breaks some Xamarin.Android AOT tests.
This commit fixes the issue by adding a new `ld-name` option to the AOT
compiler allowing one to specify just the name of the linker binary to
use. The rest of the toolchain mechanics doesn't change.
|
