Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Attention massive speed up of the debugger

<< < (4/7) > >>

oBFusCATed:
Maybe this code causes the problem:


--- Code: ---void GDB_driver::ParseOutput(const wxString& output)
{
    m_Cursor.changed = false;

    // Watch for initial debug info and grab the child PID
    // this is put here because we need this info even if
    // we don't get a prompt back.
    // It's "cheap" anyway because the line we 're after is
    // the very first line printed by gdb when running our
    // program. It then sets the child PID and never enters here
    // again because the "want_debug_events" condition below
    // is not satisfied anymore...
    if (platform::windows && want_debug_events)
    {
        wxRegEx* re = 0;
        if ((m_GDBVersionMajor > 6 || (m_GDBVersionMajor == 6 && m_GDBVersionMinor >= 7)) &&
            output.Contains(_T("CREATE_PROCESS_DEBUG_EVENT")))
        {
            re = &reChildPid2;
        }
        else if (m_GDBVersionMajor <= 6 && output.Contains(_T("do_initial_child_stuff")))
        {
            re = &reChildPid;
        }

        if (re)
.
.
.


--- End code ---

Maybe we should do the splitting here

--- Code: ---void DebuggerGDB::ParseOutput(const wxString& output)
{
    if (!output.IsEmpty() && m_State.HasDriver())
    {
        m_State.GetDriver()->ParseOutput(output);
    }
}

--- End code ---

Can you test?

Jenna:

--- Quote from: oBFusCATed on November 03, 2009, 10:26:28 pm ---Maybe this code causes the problem:

[...]

Can you test?


--- End quote ---

I will test it, if I am at work.

Jenna:
The problem we have, is that ParseOutput (in gdb_driver.cpp) relies on strings that belongs together and begin with special sequences, like gdb: or Warning:,  or do not contain anything but the response to one command (everything beginning with the GDB_PROMPT is removed inside the if(cmd)-clause).

But with your patch we can get output-strings that contain multiple lines of gdb's output.
This behaviour can break parsing (might depend on system load and whatever).

So the whole ParseOutput-function has to be overworked to work reliable with your patch.
The question is, whether the splitting and extra-parsing will eat up the time we save with the patch.

oBFusCATed:
Do you have sample output from gdb? On linux I've no problems with it.

There is an easy fix you could try (pseudo code below):

--- Code: ---void DebuggerGDB::ParseOutput(const wxString& output)
{
    if (!output.IsEmpty() && m_State.HasDriver())
    {
        wxStringArray lines = split(output, '\n');

        for(int ii = 0; ii < lines.count(); ++ii)
             m_State.GetDriver()->ParseOutput(lines[ii]);
    }
}

--- End code ---

This one should simulate the old behaviour...

Jenna:
Your code does not work, here is a corrected version (EDIT: I overread that it is pseudo-code, sorry):


--- Code: ---void DebuggerGDB::ParseOutput(const wxString& output)
{
    if (!output.IsEmpty() && m_State.HasDriver())
    {
        wxArrayString lines = GetArrayFromString(output, _T('\n'));

        for(int i = 0; i < lines.GetCount(); ++i)
             m_State.GetDriver()->ParseOutput(lines[i]);
    }
}

--- End code ---

I'm not sure if it can work reliably.
Can we reach OnGDBOutput, OnGDBError or the OnTimer-function while we are still parsing splitted output ?
If yes we would most likely mess up the order we send the data to the drivers ParseOutput.

Nevertheless, I attach a file containing the output of debugger's debug-log.
I just wrote the output-parameter from ParseOutput into the log.

[attachment deleted by admin]

Navigation

[0] Message Index

[#] Next page

[*] Previous page