Capture and display GNAT Aada GPS compile date/time
Running GNAT Ada/GPS builds and I want to capture and display the date/time of the compile build to my user interface. Must I read the executable each time, or does the gpsbuild generate statistics I can capture.
Put("Build date/time are "); put(gpsbuild.datetime, Width =>10);
New_line;
Version Date Time ...
Main Menu My Program
Start Program 1
Run Set Up 2
Enter selection:
As far as I can see, in GNAT GPS to display build number in "about" dialog they use placeholders in config file and substitute them with real values in configure file with help of AC_SUBST routine. Not so easy way, but probably most optimal since AdaCore self do it.
Related
I have a single file of CUDA code compiled to intermediate language PTX code, example.ptx. I would be interested to start poking around with this short file, trying to understand how it works.
I don't have previous experience fiddling around with intermediate code representation, but what I gather is that I can some how print out a figure of the control flow, to support me trying to reverse engineer this. Cuda Binary Utilities mention nvdisasm and shows nice Graphviz figures of the control flow, but it seems to work only for cubin files. I understand that these cubin files are optimized further from PTX, depending on the current GPU architecture.
My question is: Can I use nvdisasm to generate control flow image from example.ptx, or compile the ptx file to a cubin file, and use that to generate the image?
or compile the ptx file to a cubin file, and use that
Yes, you can do that. Compile your ptx file to a cubin with:
nvcc example.ptx -cubin
(the result will be in example.cubin or you could add e.g. -o myfile.cubin to name it something else)
This cubin file can be fed to nvdisasm for processing.
While running an executable in gdb, I encountered the following error:
Program received signal SIGFPE, Arithmetic exception.
0x08158307 in radtra_ ()
How do I understand what line number and file does 0x08158307 without recompiling or otherwise modifying the source? if it helps, the source language was Fortran.
How do I understand what line number and file does 0x08158307 without recompiling or otherwise modifying the source?
That isn't easy. You could use GDB disassemble command, look for access to global variables and CALL instructions, and make a guess where inside radtra_ you are. This is harder the larger the routine is, the more optimizations compiler has applied to it, and the fewer calls and global variable accesses are performed.
If you can't guess, your only options are:
Rebuild the application adding -g flag, but leaving all other compile options unmodified, then use addr2line to translate the address to line number. (This is how you should build the application from the start.)
If you can't rebuild the entire application, rebuild just the source containing radtra_ (again with same flags, but add -g). You should be able to match the output from objdump -d radtra.o with the output from disassemble. Once you have a match, read output from readelf -wl radtra.o or objdump -g radtra.o to associate code offsets within radtra_ with source lines that code was generated from.
Hire an expert to guess for you. This wouldn't be cheap, as people skilled in this kind of reverse engineering are usually gainfully employed and value their time.
I'm pretty new to linux, and I have a few questions about kernel module programming. I'm using ubuntu and C to make my .ko files. I'm trying to make a module that will execute program /b instead of /a whenever program /a is called. any tips?
also, even with printk (KERN_EMERG...), it won't print to the terminal. is there a setting i'm missing, or does ubuntu not do that?
Thanks a lot!
You may need to fiddle with the settings in /proc/sys/kernel/printk, which controls which levels are printed to the console. From proc(5):
/proc/sys/kernel/printk
The four values in this file are console_loglevel,
default_message_loglevel, minimum_console_level, and
default_console_loglevel. These values influence
printk() behavior when printing or logging error
messages. See syslog(2) for more info on the
different loglevels. Messages with a higher priority
than console_loglevel will be printed to the console.
Messages without an explicit priority will be printed
with priority default_message_level.
minimum_console_loglevel is the minimum (highest)
value to which console_loglevel can be set.
default_console_loglevel is the default value for
console_loglevel.
Note that, like nice(2) values, the lower values have higher priorities.
The easiest way to make an execve() for path /foo/a to execute /foo/b is to bind-mount /foo/b on top of /foo/a:
mount -obind /foo/b /foo/a
No kernel module is required.
Doing this same task with a kernel module would be significantly more work; the LSM interface may provide you with some assistance in figuring out when exactly your target is being executed. If you're looking for a starting point, do_execve() in fs/exec.c is where to start reading. Be sure to have ctags installed, run, and know how to use your editor's ctags integration, to make reading the code significantly easier.
Answer about printk:
It prints to the console, not the terminal. But what's the console?
You can find its TTY in /proc/cmdline. Normally it's tty0, which means the screen connected to the computer.
If you connect via SSH/TELNET, surely you won't see this.
If you're working in a graphical environment (Gnome/KDE), you may need something like alt-F1/F2 to switch to a text mode TTY.
You can also use the dmesg command to see the messages.
I know that this is an old topic for vfp programmers. Still, I want to ask for advices that can improve the printing time for my particular case.
I recently asked to change a report written in vfp. It use commands such as fputs, etc. The user prints this report in a dot matrix printer and of course : no problem. But the user asked for column addition and some complex calculation in the report. We tried to avoid paper size changes. So my initial solution was to rework the report using report designer, and set the page orientation to landscape. The result is so slow when printed.When I open the print queue, it even shows error - printing status!
I've tried to instal the printer driver in my local PC ( the machine where I compiled the exe) and selected this printer, both with 'save printer environment' checked and unchecked. Still the same result.
Any suggestions? Other tricks for my case are welcomed. Thanks in advance.
Sometimes, and not sure if its your case, when creating a report in VFP, it saves the printer environment based on the computer used to develop it (ie: your machine). To check, and since all reports are nothing but .DBF tables renamed, try the following. Open the report as a table
USE YourReport.frx (you have to explicitly include the .frx extension)
BROWSE
The first line in the report is your environment information that includes paper size info, orientation and even printer information. Double click in the column "Expr". The only things you probably need in this column are
ORIENTATION=1 (or 0)
it may have other stuff and look something like
DRIVER=winspool
DEVICE=\some\printershare
OUTPUT=IP_192.168.1.22
ORIENTATION=1
PAPERSIZE=1
SCALE=100
ASCII=0
COPIES=1
DEFAULTSOURCE=15
PRINTQUALITY=600
COLOR=2
DUPLEX=2
YRESOLUTION=600
TTOPTION=3
COLLATE=0
You can remove the rest of it. Next, close this column and tab over about 10 more columns to "Tag" and "Tag2". They are also MEMO type fields. Open them up. Remove ALL data out of these two columns... BUT ONLY FOR THE FIRST ROW!!!! If you open them, you would see more embedded stuff about the printer, just remove it completely. Do NOT do a global replace to blank for all rows as that will kill the report content... ONLY the first row.
All this being said, I can't guarantee, but it may be the culprit... but then again, doing direct output on old dot-matrix printers might actually be faster than all the fancy rendering the printer drivers are doing.
Trying to print a report from the report designer through the windows driver to a dotmatrix printer will never be acceptably quick.
That's why they originally did the report using commands.
Your choices are either change the printer to a laser printer (probably not possible I'm guessing) or change the report back to the old style.
It's hardly difficult to print fast on a dot matrix printer with VFP reports, you should do it on a raw mode, but not on ?? or ??? way, I mean on API calls like this:
--- RawPrint VCX ---
http://www.universalthread.com/ViewPageNewDownload.aspx?ID=9556
You can use a wrapper, with kind-of "Formats" support it's a commercial software but it's worthy if you need to do a lot of reports with this kind of printer:
--- DosPrint 4 ---
http://www.victorespina.com.ve/hs/es/index.php/DOSPrint4_%28VFP%29
(disclaimer: the developer of DosPrint 4 it's a friend of mine, and I worked with him testing and supporting on the previous version DosPrint 3 on the spanish MS-VFP newsgroups and http://Portalfox.com)
Try using the Microsoft Generic Text only print driver
I have created an image, using Platform Builder, for Windows CE6.
As per the legal agreement, I then 'licensed' the NK.BIN image file, again using Platform Builder, using a purchased run-time key that came with 100 licenses.
How can I test that this process has worked?
What is 'different' in the image? Is there a command/action that can be performed to identify a legally stamped CE6 image?
If you are trying to determine if the NK.bin has been built with the correct PID then Stampbin should do the trick:
http://msdn.microsoft.com/en-us/library/ee504718.aspx
Otherwise a search on Viewbin seems to be positive as well:
http://msdn.microsoft.com/en-us/library/ms938075.aspx:
You can use Viewbin.exe tool like "viewbin -t nk.bin" which will give an output comprised of PID[0] - PID[9]. If all these values are 0x00000000 then it means your runtime image is not stamped, otherwise it is stamped.