How can I enable debug mode in a dpdk-based application? - c

I encounter some errors when running a dpdk-based application. I find the error occurs when invoking rte_eth_dev_configure() function provided by dpdk library. The error code is -22. However, I want the application to show more debug information so that I can quickly focus on the error part.
I did RTFM and modified $RTE_SDK/build/.config. I turned RTE_LIBRTE_ETHDEV_DEBUG to be y. But It didn't work. Where does rte_vlog() function put log messages?
Would you like to help me? Any suggestion is appreciated!

You should also change the default log level, otherwise all the debug messages will be compiled out during the compilation, i.e.:
RTE_LOG_LEVEL=RTE_LOG_DEBUG
RTE_LIBRTE_ETHDEV_DEBUG=y
Please also have a look at EXTRA_CFLAGS. You might also want to add the debug symbols and disable optimizations, i.e.:
make EXTRA_CFLAGS="-O0 -g" ...

I add CONFIG_ RTE_LIBRTE_ETHDEV_DEBUG=y to the ${RTE_SDK}/config/defconfig_{RTE_TARGET} config file and rebuild the target. It works.

Related

layout next shows [ No Source Available ]

I can't understand why 'layout next' has stopped showing code. It worked for some time and i was happy with 'layout next' option but now i constantly see the error. Awkwardly enough i could find only one question relating that topic which doesn't seem to solve the problem. Any ideas how to bring this function back?
Maybe i should find some compilation flag to enable this?
EDIT:
Make sure you add -g flag on compilation and type run after 'layout next' window have appeared.
No Source Available
The error means literally that: GDB doesn't know where the source for the current program location is.
There are several possible reasons:
you have not started the program yet
you built your program without debugging info (without -g flag)
you are stopped inside a system library
you moved the source to a different location after the program was built

Eclipse: Break at address "0xXXXX" with no debug information available, or outside of program code

I got this message when I am to run the debugger on Softconsole. Is there any specific setting I should set to avoid this error message? Thanks in advance.
You should set a breakpoint at the beginning of your program, and step through until you can narrow down what function(s) or data is causing the break.
If you will use the recommended "workspace.examples" or base your workspace on a copy of the "workspace.empty" (depending on the version of SoftConsole this can happen automatically), then you will not see the issue.

How to make FlashDevelop show line error and where it happened with Haxe?

I've been using Haxe for a while and I'm debuging with the Windows target (OpenFL).
When I put a try/catch somewhere it just says for example "Null object reference" - it doesn't say the line number and the class, so I have to keep putting traces to find in which line it has thrown the error.
Can someone help me?
You might need to enable stack traces by adding the following define to your project.xml file if you're compiling in release mode:
<haxedef name="HXCPP_STACK_LINE" />
Also, you won't be able to catch null reference exceptions or get stack traces for them unless the following is defined (for performance reasons):
<haxedef name="HXCPP_CHECK_POINTER" />
With these two, you should see a stack trace in FlashDevelop's Output panel.
You can find some good info on these flags and hxcpp debugging in general here. You might also want to check out the crashdumper library.

Syntastic C make checker not reporting errors

I'm writing C code and was initially using the gcc checker. Errors were reported in the C file. Lots of errors that didn't matter were being reported due to, for instance, no include directory switches on the gcc command line in the checker. Because we're using icc and it feels unwieldy to setup all of the parameters that are already setup in our makefile, I decided to switch over to using the make checker.
Upon switching to the make checker, I did not get any results. Looking at the makeprg command in make.vim, it is make -sk. I realized that our makefile was not setup to do syntax checking, so I created a new target called syntax_check that added the -fsyntax-only and -c flags. I then changed the make.vim makeprg command to make -sk clean syntax-check so that the appropriate target is run.
When I save the file I watched top in another window and saw that the build is occuring. However, I'm still getting no errors. By this, I mean I don't see the green sidebar indicating lines that did not have errors. Running :Errors does not bring up the location list.
Any ideas? And is my understanding of how to look at the generated errors in syntastic wrong (which it may very well be)?
As a side note for the question here, I've also got this question in on the Syntastic github page here.
It turns out that the errorformat was wrong for handling icc. This, of course, makes total sense.
The errorformat for icc that I've got so far is:
let errorformat = '%W%f(%l): %tarning #%n: %m,%E%f(%l): %trror: %m'
I will add more to this as I find errors that aren't covered by this format or find that I need different formatting.

Osgviewer cow does not view a cow?

I installed OpenSceneGraph 3.0.1using MacPorts.
I've tried osgversion -> OpenSceneGraph Library 3.0.1. I downloaded the OpenSceneGraph-Data.
Everything seems working well than osgviewer cow.osg takes hours without viewing anything !
please I need help ? is there a way to debug ?
Make sure you have defined the OSG_FILE_PATH environment variable and that it points to the data directory (the one with 'cow.osg').
You can then set OSG_NOTIFY_LEVEL to DEBUG_INFO to get extended information printed to the console. If for any reason the file could not be loaded correctly you will see where to start to troubleshoot.
You can also try to run
$ osgviewer --image /path/to/an/image.png
to test if the plugins work correctly.
Plugins are named e.g. osgdb_jpeg.dylib so you can look for these to make sure they have been built properly along with the core libraries and programs.
Try setting the notify level to DEBUG : Tips And Tricks
$ export OSG_NOTIFY_LEVEL=DEBUG
and run it and see if it says what's going on/going wrong.

Resources