Skip to content

Conversation

@sdmaclea
Copy link
Contributor

@sdmaclea sdmaclea commented May 7, 2020

Add libunwind_xdac

Revise CMake files to enable compiling libunwind for UNW_REMOTE_ONLY

Add minimum set of posix prototypes and constants to enable compilation
Add minimum implementation of posix functions to satisfy linker.

Copy freebsd-elf headers from mono include directory
Cleanup comment

Fix GCC constructs not supported by VC++

Use TARGET variables to configure libunwind

Add PAL_VirtualUnwindOutOfProc to libunwind_xdac

/cc @hoyosjs

Add libunwind_xdac

Revise CMake files to enable compiling libunwind for UNW_REMOTE_ONLY

Add minimum set of posix prototypes and constants to enable compilation
Add minimum implementation of posix functions to satisfy linker.

Copy freebsd-elf headers from mono include directory
Cleanup comment

Fix GCC constructs not supported by VC++

Use TARGET variables to configure libunwind

Add PAL_VirtualUnwindOutOfProc to libunwind_xdac
@sdmaclea sdmaclea added this to the 5.0 milestone May 7, 2020
@sdmaclea sdmaclea requested review from janvorli and mikem8361 May 7, 2020 16:13
@sdmaclea sdmaclea self-assigned this May 7, 2020
@ghost
Copy link

ghost commented May 7, 2020

Tagging subscribers to this area: @tommcdon
Notify danmosemsft if you want to be subscribed.

@janvorli
Copy link
Member

janvorli commented May 7, 2020

@sdmaclea this is overall problematic. We don't want to make any changes to the libunwind sources in our repo since I expect that we would need to update them in the future from the upstream and making them diverse would cause pain once we need to sync. The exception is the CMakeLists.txt which is ours, so we can do whatever we want there.
The way we should go is to make the changes that need to be in the existing sources in the upstream libunwind.
I would also move the files that you've added as brand new to a folder out of the libunwind (say libunwind_crossdac or something along the lines side by side with the libunwind) to keep the strong separation between the original libunwind and our private stuff.

void* mmap(void *addr, size_t length, int prot, int flags, int fd, size_t offset)
{
// We shouldn't be doing anything other than anonymous mappings
if ((flags & MAP_ANON) == 0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: This should be MAP_ANONYMOUS as MAP_ANON is deprecated.

if ((flags & MAP_ANON) == 0)
return MAP_FAILED;

return malloc(length);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MAP_ANONYMOUS guarantees a zero-initialized buffer, shouldn't we call memset on the buffer that was malloc'ed?

return 0;
}

ssize_t read(int fd, void *buf, size_t count)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Spacing?

@sdmaclea
Copy link
Contributor Author

Closing in favor of #37521

@sdmaclea sdmaclea closed this Jun 11, 2020
@sdmaclea sdmaclea deleted the WindowsUnwind branch September 26, 2020 16:53
@ghost ghost locked as resolved and limited conversation to collaborators Dec 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants