Author Topic: CodeBlocks and Codesourcery GDB  (Read 70246 times)

Offline ziss_dm

  • Single posting newcomer
  • *
  • Posts: 4
Re: CodeBlocks and Codesourcery GDB
« Reply #30 on: April 20, 2012, 10:51:19 am »
Hi,

I have spent some time investigating this issue and found the following:
1) The CodeSourcery gdb is compilled with version of MinGW which uses both \r  and \n as an EOL
2) The wxWidget text stream is converting \n to the \n\r

As a result gdb receives 2 EOLs.

This is a quick fix:
Code

void PipedProcess::SendString(const wxString& text)
{
    //Manager::Get()->GetLogManager()->Log(m_PageIndex, cmd);
    wxOutputStream* pOut = GetOutputStream();
    if (pOut)
    {
        wxTextOutputStream sin(*pOut);
        sin.SetMode(wxEOL_UNIX);
        wxString msg = text + _T('\n');
        sin.WriteString(msg);
    }
}


which works fine on windows.

This is a test build:
http://mwc-ng.googlecode.com/files/CodeBlocks_svn_gdb.zip

regards,
ziss_dm
« Last Edit: April 20, 2012, 11:00:22 am by ziss_dm »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6035
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: CodeBlocks and Codesourcery GDB
« Reply #31 on: April 20, 2012, 11:14:16 am »
Hi,

I have spent some time investigating this issue and found the following:
1) The CodeSourcery gdb is compilled with version of MinGW which uses both \r  and \n as an EOL
2) The wxWidget text stream is converting \n to the \n\r

As a result gdb receives 2 EOLs.

This is a quick fix:
Code

void PipedProcess::SendString(const wxString& text)
{
    //Manager::Get()->GetLogManager()->Log(m_PageIndex, cmd);
    wxOutputStream* pOut = GetOutputStream();
    if (pOut)
    {
        wxTextOutputStream sin(*pOut);
        sin.SetMode(wxEOL_UNIX);
        wxString msg = text + _T('\n');
        sin.WriteString(msg);
    }
}


which works fine on windows.

This is a test build:
http://mwc-ng.googlecode.com/files/CodeBlocks_svn_gdb.zip

regards,
ziss_dm
I think you can supply a patch, so that debugger developers (mostly obf) can quickly review it. (I'm not familiar with gdb for embedded system)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: CodeBlocks and Codesourcery GDB
« Reply #32 on: April 20, 2012, 11:28:11 am »
ziss_dm:
Search the forum. I've investigated this issue and have made a better patch.
I won't commit it because Codesourcery devs should fix their gdb or give plausible reason for this behaviour.
If you know how to contact them, please do so or provide the contact details in this topic or on PM.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ziss_dm

  • Single posting newcomer
  • *
  • Posts: 4
Re: CodeBlocks and Codesourcery GDB
« Reply #33 on: April 22, 2012, 03:09:03 am »
Hi OBF,

Quote
Search the forum. I've investigated this issue and have made a better patch.

Sorry about that..  ::)

And I think you right, it would be ideal if CS could fix that. But I do not think, they going to do that in nearest future.  :) From other point of view, it is quite safe to assume \n as EOL on windows. So, if you could limit this change only for windows and post patch, it would be really helpful...

regards,
ziss_dm

Offline martind

  • Multiple posting newcomer
  • *
  • Posts: 47
Re: CodeBlocks and Codesourcery GDB
« Reply #34 on: May 28, 2012, 11:22:56 am »
Just in case you are not aware, ARM are sponsoring a GCC project now: https://launchpad.net/gcc-arm-embedded

However, not tried with CodeBlocks yet.


Martin.

MF

  • Guest
Re: CodeBlocks and Codesourcery GDB
« Reply #35 on: June 11, 2012, 01:47:02 am »
I've tried the GCC ARM toolchain at Launchpad.net.  I ran into a problem using it with the J-Link GDB Server.  After connecting to the GDB Server it would always throw the following error: "Remote 'g' packet is too long".  The Codesourcery toolchain's GDB client does not have this problem.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: CodeBlocks and Codesourcery GDB
« Reply #36 on: June 11, 2012, 07:56:04 am »
MF:
Does it work from the command line?
If it doesn't it is not C::B's problem...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline martind

  • Multiple posting newcomer
  • *
  • Posts: 47
Re: CodeBlocks and Codesourcery GDB
« Reply #37 on: June 20, 2012, 11:42:06 pm »
I know an openocd developer and he says the remote 'g' packet problem was fixed a while back. However problem actually lied with CodeSourcery?

If you get more recent version of OpenOCD problem should be fixed.

Offline Dvorkin

  • Multiple posting newcomer
  • *
  • Posts: 11
Re: CodeBlocks and Codesourcery GDB
« Reply #38 on: February 26, 2014, 11:22:18 am »
There is not allowable "carriage return" at the end of gdb exe name in the gdb-cb-brige.cfg