GDB path problem

[Joerg]

Hi,

seems like embedded development is not in the focus
of the codeblocks community.  :?

For a long a long time now I can not use codeblocks
for remote debugging because of a annoying bug.
Trying to set a breakpoint always results in an error like:

> break "D:/Projekte/icps-sw/src/error_handler.c:1235"
No source file named D:/Projekte/icps-sw/src/error_handler.c.

Seems like GDB has problems with the absolute path?

Changing the advanced setting
'Use full path for source files (GDB workaround)'
does not change anything.

Running GDB from command line works.

Greets,
Joerg

[Jenna]

> break "D:/Projekte/icps-sw/src/error_handler.c:1235"
No source file named D:/Projekte/icps-sw/src/error_handler.c.

Seems like GDB has problems with the absolute path?

This message is normal, if the library the source belongs to is not loaded at startup.

Can you provide a small test-project where the error occurs ?

If it's too big, or you have to (want to) send the full project, you can send it via E-Mail (should be shown in profile, if not on my website).
Which versions of gcc, gdb and C::B do you use ?

Changing the advanced setting
'Use full path for source files (GDB workaround)'
does not change anything.

If the source is on another drive, the relative and the absolute path are identical.

[Joerg]

Hi Jens,
thanks for reply.

Can you provide a small test-project where the error occurs ?

I sent a demo project to the address I found on your website, starting with debian.

Which versions of gcc, gdb and C::B do you use ?

It's one of the last Yagarto toochains:
GCC 4.2.2
GDB 6.8.50

If the source is on another drive, the relative and the absolute path are identical.

It's not on another drive but on level up(../).
You should get the error if you try to set a beakpoint in
file sub.c of my demo project.
I would choose another code organization next time,
but as GDB on command line can deal with it..

[Jenna]

Hi Joerg,

downloading the toolchain wil need about 1:30 hours (I am at home and we still get nothing faster than ISDN  :cry: ), but a short look on the Build options show me a missing "-g" option.

Does this only happen accidently for this (demo) project ?

If not this is most likely causing your problems.

And you definitely have to turn on "Use full paths for source files (GDB workaround)".
I tested it with a similar constellation (source-file of a dll one level below projects root-dir).

Otherwise gdb silently ignores the breakpoint. (Except for the message about pending breakpoint).

The full path is needed at compile time, not while debugging, so you don't see a difference in debuggers debug-log.

[rhf]

This may not be applicable, but I thought I should mention it.

http://forums.codeblocks.org/index.php/topic,9295.msg66321.html#msg66321

and see tdragon's comment on

http://sourceforge.net/tracker/index.php?func=detail&aid=2145427&group_id=200665&atid=974439

[Jenna]

And you definitely have to turn on "Use full paths for source files (GDB workaround)".
I tested it with a similar constellation (source-file of a dll one level below projects root-dir).

Otherwise gdb silently ignores the breakpoint. (Except for the message about pending breakpoint).

The full path is needed at compile time, not while debugging, so you don't see a difference in debuggers debug-log.

As I wrote before you need absolute path at compile-time, but you use a makefile.
That means not C::B generates the commands, but make does it using the information of the makefile.
Therefore C::B can not set the absolute path.

To avoid the problem, you either have to change your makefile manually, or try to switch the whole project to a real C::B project.

[Joerg]

Hi Jens, rhf,

thanks for replying so quickly.

If I change the paths in the makefile to absolute paths breakpoints work! 

But I don't get the point here.
GDB on command line doesn't seem to need absolute paths.
So why does C::B need them, and where?

There is a nice mix of back and forward slashes also,
as mentioned by rhf:

Code

>>>>>>cb_gdb:
> break "D:/Projekte/icps-sw/src/error_handler.c:1235"
Breakpoint 2 at 0x6c00: file D:\Projekte\icps-sw\src/error_handler.c, line 1235

I can not switch to a C::B  controller project, but I can
live with this absolute path workaround.

[Jenna]

There is a nice mix of back and forward slashes also,
as mentioned by rhf:

Code

>>>>>>cb_gdb:
> break "D:/Projekte/icps-sw/src/error_handler.c:1235"
Breakpoint 2 at 0x6c00: file D:\Projekte\icps-sw\src/error_handler.c, line 1235

The first line is the command C::B sends to the debugger, the second one is the answer from gdb.

About the problem with the absolute path:
I played a little bit:
If a prgram is compiled with absolute paths, gdb also needs them and if you compile it with relative paths gdb only works if you set the bp with relative path, too.

No time to go deeper in it at the moment (have to work for money a little bit now).

[Joerg]

No time to go deeper in it at the moment (have to work for money a little bit now).

Thanks anyway.

If a program is compiled with absolute paths, gdb also needs them
and if you compile it with relative paths gdb only works if you set the bp with relative path, too.

I don't see any working option to set breakpoints with relative paths in C::B.
Looking at the .elf file I can see the paths changed from relative to absolute.
Maybe it's just a problem where to start GDB?

BTW:
Any news about the fact that it's not possible to send a 'break' command to GDB under Windows?
I think someone wanted to add a button issuing a telnet command.

[mariocup]

Hi,

in the executables of embedded targets debug information normally contains relative paths, but CB uses absolute pathes to set e.g. breakpoint. Under Linux this is not a problem, since no drive letter are used and setting breakpoint with absolute paths works. Under windows however currently it is not possible to debug files (like setting breakpoints) correctly. Is there a CB setting or workaround available for setting breakpoints with a relative path?

[ollydbg]

Hi,

in the executables of embedded targets debug information normally contains relative paths, but CB uses absolute pathes to set e.g. breakpoint. Under Linux this is not a problem, since no drive letter are used and setting breakpoint with absolute paths works. Under windows however currently it is not possible to debug files (like setting breakpoints) correctly. Is there a CB setting or workaround available for setting breakpoints with a relative path?

@mariocup

Nowadays, I'm doing some coding on breakpoints persistent. So, I read some source code of debuggerGDB.

http://forums.codeblocks.org/index.php/topic,10704.0.html

Now, I can confirm that all the file was recorded and used in "absolute path", you can see a screenshot ( I just debug codeblocks in codeblocks, , set a breakpoint in AddBreakpoint function)


By ollydbg at 2009-06-20

And

Code

int DebuggerState::AddBreakpoint(const wxString& file, int line, bool temp, const wxString& lineText)
{
    wxString bpfile = ConvertToValidFilename(file);

    // do we have a bp there?
    int idx = HasBreakpoint(bpfile, line);
    // if yes, remove old breakpoint first
    if (idx != -1)
        RemoveBreakpoint(idx, true);
    // create new bp
    Manager::Get()->GetLogManager()->DebugLog(F(_T("add bp: file=%s, bpfile=%s"), file.c_str(), bpfile.c_str()));
    DebuggerBreakpoint* bp = new DebuggerBreakpoint;
    bp->type = DebuggerBreakpoint::bptCode;
    bp->filename = bpfile;
    bp->filenameAsPassed = file;
    bp->line = line;
    bp->temporary = temp;
    bp->lineText = lineText;
    bp->userData = FindProjectForFile(file);
    return AddBreakpoint(bp);
}

But these file path can transfered from "absolute path" to "relative path". Which is the way I have done to save all the breakpoints in a XXXX.bps file near yourproject.cbp.

You can see the code in:
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2775&group_id=5358

Thanks!

[MortenMacFly]

But these file path can transfered from "absolute path" to "relative path". Which is the way I have done to save all the breakpoints in a XXXX.bps file near yourproject.cbp.

BTW: This won't work then if the files are on different drives on Windows. ;-)

[mariocup]

Hi,

the strange thing I found is that gdb 6.8 (from http://www.tdragon.net/recentgcc/) is able to set breakpoints in Code::Blocks and the GDB path problem does not exist. If I try to set breakpoint with a "own" compiled e.g. arm gdb the settings of breakpoint fails. My colleague reviewed yesterday the source code and found the problem. In the file util.c it exists a call to the function realpath and this function has been empty. This functionality realpath to handle paths under win32 correctly had been in the libiberty sources. I copied this functionality in the util.c source and generated gdb and then I am able to set breakpoints correctly. Does anyone know why the gdb 6.8 version from tdragon works correct (is it a patched version?). Is this a know problem in the gnu community (I googled a lot but did not find any adequate answer for it).

If it is of interest I can send the corresponding modifications.

[ollydbg]

Does anyone know why the gdb 6.8 version from tdragon works correct (is it a patched version?).

No, I think John (author of TDM GCC) only has patches in GCC (not GDB). See: http://www.tdragon.net/recentgcc/devel.php