Ros-dev September 2014

ros-dev@reactos.org

12 participants
17 discussions

Re: [ros-dev] [ros-diffs] [jgardou] 64127: [KDGDB] - Add a callback mechanism permitting to "simulate" KD send <-> receive loop without having to actually communicate to GDB - Use that to update the program counter when con...

by Timo Kreuzer

while(1); is not really a good solution. It should be something that is visible in GDB. But I fear that a KeBugCheck() won't work here, since it will rely on a working KD connection. Maybe a KD_ASSERT() macro, that calls KdAssert() on failure or something, resets the GDB connection somehow, issues a debug print and then halts. Am 12.09.2014 22:23, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Fri Sep 12 20:23:08 2014 > New Revision: 64127 > > URL: http://svn.reactos.org/svn/reactos?rev=64127&view=rev > Log: > [KDGDB] > - Add a callback mechanism permitting to "simulate" KD send <-> receive loop without having to actually communicate to GDB > - Use that to update the program counter when cont'ing a breakpoint > Now cont'ing an assertion failure is possible, since we actually get beyond the int 3 instruction > > Modified: > trunk/reactos/drivers/base/kdgdb/gdb_input.c > trunk/reactos/drivers/base/kdgdb/kdgdb.h > trunk/reactos/drivers/base/kdgdb/kdpacket.c > > +) > +{ > + DBGKD_MANIPULATE_STATE64* State = (DBGKD_MANIPULATE_STATE64*)MessageHeader->Buffer; > + > + /* We just confirm that all went well */ > + if ((PacketType != PACKET_TYPE_KD_STATE_MANIPULATE) > + || (State->ApiNumber != DbgKdSetContextApi) > + || (State->ReturnStatus != STATUS_SUCCESS)) > + { > + /* Should we bugcheck ? */ > + while (1); > + } > +} > + > +static > +KDSTATUS > +SetContext( > + _Out_ DBGKD_MANIPULATE_STATE64* State, > + _Out_ PSTRING MessageData, > + _Out_ PULONG MessageLength, > + _Inout_ PKD_CONTEXT KdContext, > + _In_opt_ KDP_MANIPULATESTATE_HANDLER ManipulateStateHandler > +) > +{ > + State->ApiNumber = DbgKdSetContextApi; > + State->Processor = CurrentStateChange.Processor; > + State->ReturnStatus = STATUS_SUCCESS; > + State->ProcessorLevel = CurrentStateChange.ProcessorLevel; > + MessageData->Length = sizeof(CurrentContext); > + > + if (MessageData->MaximumLength < sizeof(CurrentContext)) > + { > + while (1); > + } > + >

10 years

Re: [ros-dev] [ros-diffs] [tkreuzer] 64078: [PSEH] - On clang builds we need to do the return twice trick, since we don't have asm goto, which would allow us to specify labels in the code where we can branch to on an except...

by Thomas Faber

On 2014-09-07 23:40, tkreuzer(a)svn.reactos.org wrote: > --- trunk/reactos/lib/pseh/i386/pseh3_i386.S [iso-8859-1] (original) > +++ trunk/reactos/lib/pseh/i386/pseh3_i386.S [iso-8859-1] Sun Sep 7 21:40:07 2014 > @@ -30,6 +30,10 @@ > mov [eax + SEH3_REGISTRATION_FRAME_Esi], esi > mov [eax + SEH3_REGISTRATION_FRAME_Edi], edi > > + /* Safe the return address */ > + mov ebx, [esp] > + mov [eax + SEH3_REGISTRATION_FRAME_ReturnAddress], ebx > + > .global __SEH3$_RegisterFrameWithStackLayout > __SEH3$_RegisterFrameWithStackLayout: > I think we need to restore ebx before returning? I don't see us telling the compiler that it was clobbered anywhere.

10 years

Re: [ros-dev] [ros-diffs] [akhaldi] 64113: [GLU32] * Link with mingwex. * Allow multiple definitions at link time because longjmp exists in both our msvcrt and mingwex. CORE-8516

by Timo Kreuzer

Are you sure that we will link to the correct one? I doubt that the one from mingwex is compatible. Am 11.09.2014 12:13, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Thu Sep 11 10:13:05 2014 > New Revision: 64113 > > URL: http://svn.reactos.org/svn/reactos?rev=64113&view=rev > Log: > [GLU32] > * Link with mingwex. > * Allow multiple definitions at link time because longjmp exists in both our msvcrt and mingwex. > CORE-8516 > > Modified: > trunk/reactos/dll/opengl/glu32/CMakeLists.txt > > Modified: trunk/reactos/dll/opengl/glu32/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/opengl/glu32/CMakeList… > ============================================================================== > --- trunk/reactos/dll/opengl/glu32/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/opengl/glu32/CMakeLists.txt [iso-8859-1] Thu Sep 11 10:13:05 2014 > @@ -114,6 +114,11 @@ > > if(NOT MSVC) > add_target_compile_flags(glu32 "-Wno-write-strings -Wno-unused-but-set-variable") > + if(CMAKE_C_COMPILER_ID STREQUAL "Clang") > + target_link_libraries(glu32 mingwex) > + #FIXME: longjmp exists in both our msvcrt and mingwex > + add_target_link_flags(glu32 "-Wl,--allow-multiple-definition") > + endif() > endif() > > add_importlibs(glu32 opengl32 gdi32 msvcrt kernel32 ntdll) > > >

10 years

Re: [ros-dev] [ros-diffs] [akhaldi] 64094: [CMAKE/CLANG] * Globally link mingwex for C modules. CORE-8516

by Jérôme Gardou

Hey Amine Is there any reason to not use our own mingwex build ? Le 09/09/2014 20:11, akhaldi(a)svn.reactos.org a écrit : > Author: akhaldi > Date: Tue Sep 9 18:11:10 2014 > New Revision: 64094 > > URL: http://svn.reactos.org/svn/reactos?rev=64094&view=rev > Log: > [CMAKE/CLANG] > * Globally link mingwex for C modules. > CORE-8516 > > Modified: > trunk/reactos/toolchain-clang.cmake > > Modified: trunk/reactos/toolchain-clang.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/toolchain-clang.cmake?rev=… > ============================================================================== > --- trunk/reactos/toolchain-clang.cmake [iso-8859-1] (original) > +++ trunk/reactos/toolchain-clang.cmake [iso-8859-1] Tue Sep 9 18:11:10 2014 > @@ -56,7 +56,7 @@ > set(CMAKE_ASM_CREATE_STATIC_LIBRARY ${CMAKE_C_CREATE_STATIC_LIBRARY}) > > # Don't link with anything by default unless we say so > -set(CMAKE_C_STANDARD_LIBRARIES "-lgcc" CACHE STRING "Standard C Libraries") > +set(CMAKE_C_STANDARD_LIBRARIES "-lmingwex -lgcc" CACHE STRING "Standard C Libraries") > > #MARK_AS_ADVANCED(CLEAR CMAKE_CXX_STANDARD_LIBRARIES) > set(CMAKE_CXX_STANDARD_LIBRARIES "-lgcc" CACHE STRING "Standard C++ Libraries") > >

10 years

by Thomas Faber

Making the member conditional but writing to it unconditionally seems like it would overflow the stack variable on GCC? On 2014-09-07 23:40, tkreuzer(a)svn.reactos.org wrote: > +#ifdef __clang__ > + void *ReturnAddress; > #endif > + /* Safe the return address */ > + mov ebx, [esp] > + mov [eax + SEH3_REGISTRATION_FRAME_ReturnAddress], ebx

10 years

Re: [ros-dev] [ros-diffs] [jgardou] 64022: [SECUR32] - Update spec file [SCHANNEL] - Update stubs list Please blame binutils

by Timo Kreuzer

Am 01.09.2014 14:21, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Mon Sep 1 12:21:16 2014 > New Revision: 64022 > > URL: http://svn.reactos.org/svn/reactos?rev=64022&view=rev > Log: > [SECUR32] > - Update spec file > [SCHANNEL] > - Update stubs list > Please blame binutils > > Modified: > trunk/reactos/dll/win32/schannel/schannel.spec > trunk/reactos/dll/win32/schannel/schannel_wine.c > trunk/reactos/dll/win32/schannel/stubs.c > trunk/reactos/dll/win32/secur32/secur32.spec > > Modified: trunk/reactos/dll/win32/schannel/schannel.spec > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/schannel/schanne… > ============================================================================== > --- trunk/reactos/dll/win32/schannel/schannel.spec [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/schannel/schannel.spec [iso-8859-1] Mon Sep 1 12:21:16 2014 > @@ -15,14 +15,14 @@ > @ stdcall InitSecurityInterfaceW() schan_InitSecurityInterfaceW > @ stdcall InitializeSecurityContextA(ptr ptr str long long long ptr long ptr ptr ptr ptr) schan_InitializeSecurityContextA > @ stdcall InitializeSecurityContextW(ptr ptr wstr long long long ptr long ptr ptr ptr ptr) schan_InitializeSecurityContextW > -@ stdcall MakeSignature(ptr long ptr long) secur32.MakeSignature > +@ stdcall MakeSignature(ptr long ptr long) schan_MakeSignature > @ stub OpenSslPerformanceData > @ stdcall QueryContextAttributesA(ptr long ptr) schan_QueryContextAttributesA > @ stdcall QueryContextAttributesW(ptr long ptr) schan_QueryContextAttributesW > -@ stdcall QuerySecurityPackageInfoA(str ptr) secur32.QuerySecurityPackageInfoA > -@ stdcall QuerySecurityPackageInfoW(wstr ptr) secur32.QuerySecurityPackageInfoW > -@ stdcall RevertSecurityContext(ptr) secur32.RevertSecurityContext > -@ stdcall SealMessage(ptr long ptr long) secur32.SealMessage > +@ stdcall QuerySecurityPackageInfoA(str ptr) schan_QuerySecurityPackageInfoA > +@ stdcall QuerySecurityPackageInfoW(wstr ptr) schan_QuerySecurityPackageInfoW > +@ stdcall RevertSecurityContext(ptr) schan_RevertSecurityContext > +@ stdcall SealMessage(ptr long ptr long) schan_EncryptMessage > @ stdcall SpLsaModeInitialize(long ptr ptr ptr) > @ stdcall SpUserModeInitialize(long ptr ptr ptr) > @ stub SslCrackCertificate > @@ -33,5 +33,5 @@ > @ stub SslGenerateRandomBits > @ stub SslGetMaximumKeySize > @ stub SslLoadCertificate > -@ stdcall UnsealMessage(ptr ptr long ptr) secur32.UnsealMessage > -@ stdcall VerifySignature(ptr ptr long ptr) secur32.VerifySignature > +@ stdcall UnsealMessage(ptr ptr long ptr) schan_DecryptMessage > +@ stdcall VerifySignature(ptr ptr long ptr) schan_VerifySignature This change is not correct. The following functions from schannel are forwarded to secur32: MakeSignature, QueryContextAttributesA/W, QuerySecurityPackageInfoA/W, RevertSecurityContext, SealMessage, UnsealMessage, VerifySignature Timo

10 years

Re: [ros-dev] [ros-diffs] [hbelusca] 64017: [BOOTVID] - Synchronize correctly arm/bootdata.c with i386, as it was done previously. - Code formatting: whitespace fixes, add braces/brackets and spaces where needed; comments s...

by Timo Kreuzer

Am 01.09.2014 01:00, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Sun Aug 31 23:00:29 2014 > New Revision: 64017 > > URL: http://svn.reactos.org/svn/reactos?rev=64017&view=rev > Log: > [BOOTVID] > - Synchronize correctly arm/bootdata.c with i386, as it was done previously. Why is that file duplicated at all, if the contents are identical?

10 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev September 2014