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@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);- }
Yeah you're not the first one to tell me that, and I wasn't really happy to write it either.
I like your approach. I will try to do as you suggest.
Thanks Jérôme
Le 12/09/2014 22:53, Timo Kreuzer a écrit :
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@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);- }
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev