Author Topic: GDB path problem  (Read 21224 times)

Offline Joerg

  • Multiple posting newcomer
  • *
  • Posts: 100
GDB path problem
« on: December 01, 2008, 10:30:57 am »
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
It's never too late to fail!

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: GDB path problem
« Reply #1 on: December 01, 2008, 01:53:16 pm »
> 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.

Offline Joerg

  • Multiple posting newcomer
  • *
  • Posts: 100
Re: GDB path problem
« Reply #2 on: December 01, 2008, 03:46:54 pm »
Hi Jens,
thanks for reply.

Quote
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.

Quote
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

Quote
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..
It's never too late to fail!

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: GDB path problem
« Reply #3 on: December 01, 2008, 04:35:14 pm »
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.

Offline rhf

  • Multiple posting newcomer
  • *
  • Posts: 123
Re: GDB path problem
« Reply #4 on: December 01, 2008, 05:28:18 pm »

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: GDB path problem
« Reply #5 on: December 01, 2008, 05:59:11 pm »
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.

Offline Joerg

  • Multiple posting newcomer
  • *
  • Posts: 100
Re: GDB path problem
« Reply #6 on: December 02, 2008, 10:35:16 am »
Hi Jens, rhf,

thanks for replying so quickly.

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

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: [Select]
>>>>>>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.
It's never too late to fail!

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: GDB path problem
« Reply #7 on: December 02, 2008, 11:03:19 am »
There is a nice mix of back and forward slashes also,
as mentioned by rhf:

Code: [Select]
>>>>>>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).

Offline Joerg

  • Multiple posting newcomer
  • *
  • Posts: 100
Re: GDB path problem
« Reply #8 on: December 02, 2008, 03:17:43 pm »
Quote
No time to go deeper in it at the moment (have to work for money a little bit now).
Thanks anyway.
Quote
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.


It's never too late to fail!

Offline mariocup

  • Moderator
  • Lives here!
  • *****
  • Posts: 587
Re: GDB path problem
« Reply #9 on: June 19, 2009, 04:30:49 pm »
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?

Online ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5223
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: GDB path problem
« Reply #10 on: June 21, 2009, 08:56:42 am »
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, :D, set a breakpoint in AddBreakpoint function)


By ollydbg at 2009-06-20

And
Code: [Select]
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!
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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9496
Re: GDB path problem
« Reply #11 on: June 22, 2009, 07:08:45 am »
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. ;-)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline mariocup

  • Moderator
  • Lives here!
  • *****
  • Posts: 587
Re: GDB path problem
« Reply #12 on: June 23, 2009, 01:26:53 pm »
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.



Online ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5223
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: GDB path problem
« Reply #13 on: June 23, 2009, 02:41:10 pm »
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
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.