summaryrefslogtreecommitdiff
path: root/dac.cmake
AgeCommit message (Collapse)AuthorFilesLines
2019-05-23Profiler attach over the diagnostics pipe (#24670)David Mason1-0/+4
Remove the old windows only profiler attach mechanism and replace it with a cross plat implementation over the diagnostics pipe
2018-08-06Only register signals and create alt exception stack in coreclr. (#19309)Mike McLaughlin1-1/+0
There was a couple of places where the DAC (IsValidObject, GetAppDomainForObject) assumed that a NULL target/debuggee address would throw an exception that would be caught by try/catch. Any other invalid address is handled with a software exception throwed by the read memory functions. In general it is a better overall design not to have any of the DBI/DAC, etc. code depend on hardware exceptions being caught. On Linux the C++ runtime sometimes can't handle it. There is a slight risk that there are other places in the DAC that make the NULL address assumption but testing so far has found any. Added PAL_SetInitializeDLLFlags as a fallback to allow the PAL_InitializeDLL flags to be set for a PAL instance for the DAC where we could still register h/w signals but not the altstack switching to reduce this risk. The flags can't be build time conditional because we only build one coreclrpal.a library that all the modules used. Having a PAL_InitializeFlags function doesn't really help either because of the PAL_RegisterModule call to PAL_IntializeDLL and the LoadLibrary dance/protocol that uses it to call the loading module's DLLMain. Add PAL_SetInitializeFlags; remove flags from PAL_INITIALIZE and PAL_INITIALIZE_DLL default. Add PAL_InitializeFlags() to allowing the default to be overriden.
2016-01-31Enabling profiling on Unix/OS X.Andreas Strid1-3/+3
2015-04-22Changed the VM's hardware exception to return if not in manged code. For ↵Mike McLaughlin1-0/+1
DAC's hardware exception handling, add hardware exception holder used to determine if a C++ exception should be thrown for a hardware exception. Cleaned up PAL initialization interactions between the debugger modules (PAL_InitializeDLL) and coreclr (PAL_InitializeCoreCLR).
2015-03-09Fix sos on window's build.Mike McLaughlin1-2/+3
2015-03-06Add a fourth parameter to the DEFINE_DACVAR macro that is the actual fully ↵Mike McLaughlin1-1/+0
qualified name of the static/global. First pass at the global DAC table support for Linux. Explicitly build the table in the coreclr module instead of extract it from the pdb and put it in a resource. Fixed the SVR gc globals in the DAC table. They had to be seperated and initialized in gceesvr.cpp. Start on global pointer table. PAL functions to write and read the DAC table address between processes. The dac table is now copied from the coreclr process to the DAC/debugger process. The tables were not being built with exactly the same defines so they weren't the same size. Fixed a bug in the read memory implementation. Still assumes pid = 0. Changed the dacTable entries to be RVAs and renabled getting the corclr module base addres (m_globalBase). Added dac table address file cleanup on coreclr shutdown. Filled in the vtable entries in the global dac table. Changed some of the VPTR_* macros to be defined on the coreclr side (RS) to defined a constructor that is used to get the vtable in dactable.cpp. These changes required default constructors to be added to some of the classes. Changed getting the vtable address to not invoke the destructors since the constructor used didn't do anything (like initialize variables, etc.). Added a TODO comment about the debuggee pid not being available in the dac table address file name. Fixed Windows build. Created a couple of new VPTR_* macros that add a default constructor only if building coreclr (not DAC) on Linux. Comment on how these DAC table functions are temporary.
2015-01-30Initial commit to populate CoreCLR repo dotnet-bot1-0/+8
[tfs-changeset: 1407945]