07-25-2018 07:12 AM
I'm debugging an application, after many days modifying the code now when I start the debug before make the first step I find in the debug window a lot of entries, I expect to find only the line I'm debugging.
In the attached image 0x000002C0 XDp_RxAllocatePayloadStream(): xdp_mst.c, line 2989
Why is that?
07-26-2018 12:06 AM
Can you please clean the workspace and give it a try again?
07-26-2018 01:16 AM
I clean the project, no differences.
Deleted several times the .metadata folder (as it freezes about every hour then sdk will not start again until delete the folder), no differences.
07-26-2018 01:50 AM
Are you seeing the same issue if you try with a different workspace also?
07-26-2018 02:02 AM
Yes, I saw the same issue in other projects with different workspaces, I try clean all and make a new project starting again from the beginning with the same source code.
It's ok for a while then start the issue.
08-08-2018 02:10 AM
From your screenshot it seems that your application code is executing something else before reaching the main function, so can you enable stop at program entry option in your debug configuration? That should stop the debugger from the very beggining point of the application so then you can try to reach the main and se what's going on.
BTW: Are you reseting the processor or system before downloading again the ELF file? Might be something is not being cleared (interrupt handler...) so you having this kind of behaviour?
08-20-2018 11:11 PM
sorry for the late reply, I already enable the "stop at program entry" but no differences, I also reset and program the FPGA each time so I think that is not related to interrupt handler not cleared, even if when a interrupt is triggered the program jump on one of the function in the list.
08-24-2018 07:23 AM
Have created the wiki below that you might find useful here:
In fact, I created a few:
08-24-2018 07:48 PM
What you are seeing is related to the GCC debug statements "cfi_..."
These debug statements are sprinkled in the generated code to identify what is held in the stack.
@ibaiehas correctly flagged the most likely root cause of that never ending stack trace back.
Don't get bother with that.
You'll more than likely see that all further (nested) function calls will have the correct trace-back information.
08-26-2018 11:46 PM
I don't understand the cause of that, I understand that it's not allowing me to debug using step by step function, as I try make a step the microblaze jump to the function in the list and if I go ahead with step by step will never go back to the main.
To debug step by step I've to put breakpoints in all lines and then use the "run" function.
08-27-2018 06:29 AM
the multiple display of XDp_RxAllocate... is one theing, single stepping is a different one.
The multiple display is caused by badly formed cfi_... statements in the code before main() and thisi has nothing to do with single stepping.
These cfi_.. statements are only used to display the stack trace back (nested called functions) and to know where "C" variables are on the stack when debugging a function.
If I remember correctly, CFI stands for Call Frame Information.
Single stepping, if done at the ASM level, does not involve any debug information from the elf file.
Single stepping "C" code involves debug information from the generated code (these cfi_... are not that debug info) as there are tags to group the multiple ASM statements that makes a single line of "C" code.
If you are not returning from the function you are single steeping into, it's more likely the code itself does not return.
Have you tried removing the compiler optimization? (set -O0).
It will be easier to see the single stepping in :"C" without optimization.