debug binary executable

Hello Alex,

Can you provide more details, such as:

-Exact CCS version

-Exact target

Alex S said:

But when I start image it execute without halt at main() like specified in settings.

Note that the auto-run to main option is for program/symbol load, not program run. If you load the program, it will auto-run to main on program load right away. If you then execute the target, it will just continue to run since main has already been passed.

ki

CCS v5, target c6678.

Ki-Soo Lee said:

auto-run to main option is for program/symbol load, not program run

I start image by the use of
GEL_MemoryLoad()
GEL_SymbolLoad()
PC = entry_point
GEL_Run()

and waiting for the CCS halt on main().

Is it correct technique?

Alex S said:

I start image by the use of
GEL_MemoryLoad()
GEL_SymbolLoad()
PC = entry_point
GEL_Run()

and waiting for the CCS halt on main().

CCS will not halt on main() in the scenario you described. If you wish to do so, you will need to manually set a breakpoint at main() first

Thanks

ki

If to use GEL_BreakPtAdd("main") than the target don't halt on main() break, but halt if to press reset in CCS. Why?

If to double click on the marker bar next to the line than it's inactive (see pic), but if to use right-click than it's work. Why?

Alex,

My apologies for the delayed response. For some reason I missed your reply.

Alex S said:

If to use GEL_BreakPtAdd("main") than the target don't halt on main() break, but halt if to press reset in CCS. Why?

I assume you are doing something like:

GEL_MemoryLoad()
GEL_SymbolLoad()
PC = entry_point

GEL_BreakPtAdd("main")
GEL_Run()

Assuming that your entry point precedes main, then that should work - you should be halted in main. If it never halts there, then something must be wrong where it never reaches main.

Alex S said:

If to double click on the marker bar next to the line than it's inactive (see pic), but if to use right-click than it's work. Why?

That 3rd breakpoint is not a CCS breakpoint but a standard Eclipse breakpoint (the littel breakpoint icon looks smaller). That will not work with the CCS debugger. The question is why a double-lick defaults to a CDT breakpoint and not a CCS one. Also the breakpoints view looks like the default Eclipse one and not the CCS one. Can you provide a screenshot of your whole CCS?

Thanks

ki

1.

Ki-Soo Lee said:

Assuming that your entry point precedes main, then that should work - you should be halted in main. If it never halts there, then something must be wrong where it never reaches main.

OnReset( int nErrorCode )
{
    ...
    PC = MC_IMAGE_START;
    GEL_Go(main);
}

for convenience and it doesn't work too.
If I add break manually then it halt on main on Restart.

2.

Ki-Soo Lee said:

The question is why a double-lick defaults to a CDT breakpoint and not a CCS one.

3.
I can't choose Launch Configuration for General Project.
So when I press F11 it says "The selection cannot be launched, and there are no recent launches" but i have launched existed conf just before that!!

4.
If I load c sources tree as General Project I have no code navigation. But it partially appear after symbols loading.

5.
I don't see printfs output in Console view.

Bump!
Is support going to support?!

Ki-Soo Lee said:

These "General" Project types (by default) are mostly used as a containers and not normally launched. There is usually no debug launch association. Also it is likely the the CDT C/C++ Indexer is not fully enabled for a "General" Project, which can explain the lack of Code navigation.

Ki-Soo Lee said:

Having a "General" project selected will default to a CDT breakpoint when double-clicking in the editor margin.

Alex S said:

Then what I should use for building outside ccs and debug build results with the same debugging functionality as the rtsc(ccs) project? Or give me another debugger.

If you want to use a project to reference your source files, I'd go with a CCS project. This is best supported by the CCS debugger. A standard C or makefile project will work fine also except for the double-clicking breakpoints issue. Starting with version CCSv6, you can set the default between CDT or CCS breakpoints but you are using an older CCS version (5.2.1)

Personally, I don't use any project if I am not building from CCS. I simply start a project-less debug session, load my program/symbols and then point CCS to the missing source files to have source level debug. As long as the source directory structure was not modified since the program was built, the debugger can find the rest of the source files. This is mentioned in slides 53-58 of the v6 Tips and Tricks Presentation (specifically Option #1)

software-dl.ti.com/ccs/esd/training/CCSv6-TipsAndTricks.pptx

Alex S said:

Btw, your gdb (linux-c6x/linux-c6x-2.0.0.63/opt/gcc-c6x/bin/c6x-uclinux-gdb) crash with segfault on view locals and several else commands.

I'm not very familiar with this package. I don't think this comes from the main software tools group of TI. It seems like many of the questions regarding linux-c6x is supported by the experts in the TI Linux forum so that would be a good place for more answers

software-dl.ti.com/ccs/esd/training/CCSv6-TipsAndTricks.pptx

I'll also see if I can find some people in the tools group who have some expertise on this.

Alex S said:

Device is c6678. This is my app (Please visit the site to view this file)

Thank you, the zip has a *.out, binary image, gel and target config. Perfect. I will look at this asap.

ki

Ki-Soo Lee said:

software-dl.ti.com/ccs/esd/training/CCSv6-TipsAndTricks.pptx

You are using v5 but I gave you the link for the v6 presentation.

Here is the v5 version:

software-dl.ti.com/ccs/esd/training/CCSv5-TipsAndTricks.pptx

Slides 50-55

Thanks

ki

Ki-Soo Lee said:

standard C or makefile project will work fine

Ki-Soo Lee said:

I simply start a project-less debug session, load my program/symbols and then point CCS to the missing source files to have source level debug

Ki-Soo Lee said:

slides 53-58 of the v6 Tips and Tricks Presentation

CCS will look for source files using relative path information stored in the debug symbols

[/quote]Debug  symbols store absolute paths.

Alex S said:

Are you joking??? It's unacceptable. In 8-core debugging it will cause dozen of clicks and dialogs. Debugger connect to target during dozen seconds already. It's already wasting of time.
HELLO. 21 century now! What is makefile??? What is manual cliking?? ALL debugging initialization and connection should work by ONE hotkey automatically in couple seconds! Any other is terrible as ccs is.

No joke, seriously.

As mentioned in the powerpoint, you just need to look for the first file and then the debugger will find the rest. And the debugger will "remember" where that first file was so that subsequent debug launches, you don't have to browse for it again. You also have to option to simply set a global debug search path if you wish (mentioned in the same tips and trick presentation) and be done with it. It is up to you.

Alex S said:

Debug  symbols store absolute paths.

It should be relative with newer build output. Long time ago it was absolute with the older build tools and COFF/STABS output. But you are using a newer compiler (7.4.11) with ELF\DWARF output. The path in the debug symbols should be all relative.

Thanks

ki

Alex S said:

Entry point precedes main.
Program reaches main.
I changed code to:

OnReset( int nErrorCode )
{
    ...
    PC = MC_IMAGE_START;
    GEL_Go(main);
}

for convenience and it doesn't work too.
If I add break manually then it halt on main on Restart.

I believe I understand what is happening here now. You GEL file loads the program binary for memory via GEL_MemoryLoad to address 0x9e000000 in DDR3. Then you load the just the debug symbols for the program via GEL_SymbolLoad. The you set the PC to 0x9e001040 and try to run to main. The issue is that the symbols you just loaded have load/run time addresses for everything in SHRAM. The entry point __c_int00 is 0x0c1fe8e0 and main is at 0x0c200d60. So when you execute the reset and try to go to main, the debugger will set the breakpoint at main using the address it has in the debug symbols loaded (0x0c200d60) and then run. Since the code loaded to DDR3 never reaches 0x0c200d60, the program never halts. When you break manually and then do a restart, the debugger will set the PC to what it thinks is the entry point of the program - which is the address for __c_int00 in the debug symbols. That address is 0x0c1fe8e0. From there, it will auto-run to main by setting a breakpoint at 0x0c200d60 and running. Now since it can reach that address, it will be halted there. But since you didn't load any code there, it isn't actually running your code. I'm playing around with a few things as I investigate further but it seems like this is what is happening...

Ki-Soo Lee said:

It should be relative with newer build output. Long time ago it was absolute with the older build tools and COFF/STABS output. But you are using a newer compiler (7.4.11) with ELF\DWARF output. The path in the debug symbols should be all relative.

Ki-Soo Lee said:

Since the code loaded to DDR3 never reaches 0x0c200d60

Ki-Soo Lee said:

But since you didn't load any code there

Ki-Soo Lee said:

When you break manually and then do a restart, the debugger will set the PC to what it thinks is the entry point of the program - which is the address for __c_int00 in the debug symbols. That address is 0x0c1fe8e0

Ki-Soo Lee said:

Now since it can reach that address, it will be halted there.

Alex S said:

Wrong. For ELF generated by 8.0.1 this command
readelf a.out --debug-dump=decodedline | grep CU | grep main.c will print
CU: /home/user/path_to_folder/main.c:

Sorry my comment was misleading. The symbols have the original full path to the source file when the program was original compiled. But the debugger can still find the source files using the relative path information once the first source file is discovered. It uses information in the debug symbols and the known location of the first file (when browsed to)

Alex S said:

See how madtool works. mcimage contain code that load program segments to the required adresses (SHRAM) and start program. Program is normally executed in SHRAM. On Suspend you could see currently executed function in SHRAM in Debug and Disassembly views.

As you figured out, I know nothing about madtool. It doesn't come from the CCS team. I wish I knew about it earlier or I would not have wasted your time. Without all that information known upfront, I was running under the assumption you were simply loading a raw binary image of your application.

Alex S said:

"it thinks"??? Debugger doesn't set PC register. I guess you absolutely don't know whereof you speak. On reset it works as on the my proving screen. The debugger halts on 0x0c200d60.

When you do a debugger restart, the debugger will set the PC to the entry point (__c_int00) if one exists. That is what the restart command does. It sets the PC to the entry point.

Alex S said:

Why it couldn't reach that before? After all, nothing has changed!

The difference (to me) is where the program is started from. When you hit restart, it sets the PC to 0x9E001040 and tries to run. When you hit reset, it sets the PC to __c_int00 (0x0c1fe8e0) and the runs to main.

Alex S said:

I want this problem to be investigated by someone more competent.

But in any case you definitely need someone more competent to help you. Someone who is knowledgeable of the MAD utilities. Technical support for the MAD utilities can be found in the C66x forums:

I will leave this thread here so that others with more knowledge in this forum can contribute.

Thanks

ki