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);
+ }
+