how can I combine two different gdb commands “info symbol” and “ptype” into single one? - nginx

in other words,Is there a command that can find the symbol at an address meanwhile use ptype show this symbol‘s detail info ?
or if there is not, how can i write a user-define command meet this needs ?
for example, now i can firstly get data struct‘s name (ngx_errlog_module_ctx) in a address use “info symbol” command, than use ptype show the data struct’s detail info like this:
(gdb) info symbol 0x80b4568
ngx_errlog_module_ctx in section .data of /usr/local/nginx/sbin/nginx
(gdb) ptype ngx_errlog_module_ctx
type = struct {
ngx_str_t name;
void *(*create_conf)(ngx_cycle_t *);
char *(*init_conf)(ngx_cycle_t *, void *);
}
but now, how can i write a user-difined command (ptype_with_address) that i can use like this :
ptype_with_address 0x80b4568
ngx_errlog_module_ctx in section .data of /usr/local/nginx/sbin/nginx
type = struct {
ngx_str_t name;
void *(*create_conf)(ngx_cycle_t *);
char *(*init_conf)(ngx_cycle_t *, void *);
}
i want to do this because i am research nginx’s code,i want write a user-defined command to show all ngx_modules's detail info, include each module's ctx member variable.

can i write a user-define command meet this need
If you have a reasonably recent version of GDB, you should be able to use built-in Python interpreter to achieve your goal.
Unfortunately, it doesn't look like you can get the gdb.Symbol from its address, you need the symbol name. In other words, it doesn't look like info symbol is currently exposed to Python interpreter in GDB.
I suggest filing a feature request in bugzilla to extend gdb.lookup_global_symbol to also accept an address.
Googling for "gdb python info symbol" revealed this thread, in which Tom Tromey (gdb developer) also asked to file a bugzilla issue, and suggested a workaround.

Related

mpi4py Split_type using openmpi's OMPI_COMM_TYPE_SOCKET

Is it possible to split a communicator using openmpi's OMPI_COMM_TYPE_SOCKET in mpi4py?
I've verified this works:
from mpi4py import MPI
comm = MPI.COMM_WORLD
sharedcomm = comm.Split_type(MPI.COMM_TYPE_SHARED)
but this does not:
socketcomm = comm.Split_type(MPI.OMPI_COMM_TYPE_SOCKET)
nor does this:
socketcomm = comm.Split_type(MPI.COMM_TYPE_SOCKET)
I've looked at the docs but I can't find anything about this.
mpi4py only provides a wrapper around standard MPI features. OMPI_COMM_TYPE_SOCKET is an Open MPI specific split type. You may still use it in mpi4py if you know its numeric value as it is just a member of a C enum:
/*
* Communicator split type constants.
* Do not change the order of these without also modifying mpif.h.in
* (see also mpif-common.h.fin).
*/
enum {
MPI_COMM_TYPE_SHARED,
OMPI_COMM_TYPE_HWTHREAD,
OMPI_COMM_TYPE_CORE,
OMPI_COMM_TYPE_L1CACHE,
OMPI_COMM_TYPE_L2CACHE,
OMPI_COMM_TYPE_L3CACHE,
OMPI_COMM_TYPE_SOCKET, // here
OMPI_COMM_TYPE_NUMA,
OMPI_COMM_TYPE_BOARD,
OMPI_COMM_TYPE_HOST,
OMPI_COMM_TYPE_CU,
OMPI_COMM_TYPE_CLUSTER
};
#define OMPI_COMM_TYPE_NODE MPI_COMM_TYPE_SHARED
Being a member of an enum means that the actual numerical value of OMPI_COMM_TYPE_SOCKET depends on its position in the enum and hence may differ from one release of Open MPI to another. You have several options here.
Hardcode the value
This is the simplest option. Open mpi.h (ompi_info --path incdir gives you its location), count the position of OMPI_COMM_TYPE_SOCKET in the enclosing enum starting with 0 for MPI_COMM_TYPE_SHARED and hardcode the value. The code may break with releases of Open MPI different from yours.
Parse mpi.h
Read mpi.h, search for enum definitions and find the one containing OMPI_COMM_TYPE_SOCKET. Provided that MPI_COMM_TYPE_SHARED is 0, the value of OMPI_COMM_TYPE_SOCKET is its 0-based index in the sequence of enum values. This depends a lot on the code in mpi.h having a specific format and can easily break if that changes.
Parse mpif.h
The Fortran interface is easier to parse as there the value is defined as:
parameter (OMPI_COMM_TYPE_SOCKET=6)
This is easily parsable with a simple regular expression. The problem is that recent versions of Open MPI split mpif.h over a couple of files that are then included from mpif.h and currently the value is in mpif-constants.h. So you may need to parse the include statements and recurse into the files they reference. Note that those are Fortran include statements and not preprocessor #include directives.
Code generation
Write a small C program that outputs the value of OMPI_COMM_TYPE_SOCKET to a Python file and run it as part of your program's setup procedure. Something like:
#include <stdio.h>
#include <mpi.h>
int main (int argc, char **argv)
{
if (argc != 2)
{
printf("Usage: mkompimod /path/to/module.py\n");
return 1;
}
FILE *fh = fopen(argv[1], "w");
if (fh != NULL) {
fprintf(fh, "COMM_TYPE_SOCKET = %d\n", OMPI_COMM_TYPE_SOCKET);
fclose(fh);
}
return 0;
}
Put that in a file named mkompimod.c. Compile with mpicc -o mkompimod mkompimod.c and run with mkompimod /path/to/ompi.py to create a Python file ompi.py with the value of OMPI_COMM_TYPE_SOCKET. Import it and use it in the call to comm.Split_type():
import ompi
socketcomm = comm.Split_type(ompi.COMM_TYPE_SOCKET)
Write a Python module in C
That's a bit involved, but you can write a C module that includes mpi.h and exports the value of OMPI_COMM_TYPE_SOCKET as a Python constant. Consult the Python documentation on how to write extensions in C.
Use the CFFI module
CFFI lets you build Python modules that wrap C libraries and writes all the glue code for you. Put the following in a file named ompi_build.py:
from cffi import FFI
ffi = FFI()
ffi.set_source("ompi", r"#include <mpi.h>")
ffi.cdef(
r"""
const int OMPI_COMM_TYPE_HWTHREAD;
... more constants here ...
const int OMPI_COMM_TYPE_SOCKET;
... even more constants here ...
"""
)
if __name__ == "__main__":
ffi.compile(verbose=True)
Run like this:
$ CC=mpicc python ompi_build.py
This will create the C module ompi.c and compile it into a loadable DSO. You may then import it and access the constant like this:
from ompi.lib import OMPI_COMM_TYPE_SOCKET
socketcomm = comm.Split_type(OMPI_COMM_TYPE_SOCKET)
CFFI provides integration with Python's distutils and you can have it automatically build the C module as part of the setup process.
Use Cython
That's what mpi4py itself is written in. It blends C and Python into a single cryptic syntax. Read the source code. Try to figure out what's going on and how to write something yourself. Can't help you there.
Whichever path you choose, keep in mind that all this pertains to the system on which the program will be running, not only the system on which the program will be developed.

How customize machine dependency in Frama-C?

I have got a 16-bit MPU which is different from x86_16 in size of size_t, ptrdiff_t etc. Can anybody give me details and clear instructions about how to customize machine dependency in Frama-C for my MPU?
There is currently no way to do that directly from the command line: you have to write a small OCaml script that will essentially define a new Cil_types.mach (a record containing the necessary information about your architecture) and register it through File.new_machdep. Assuming you have a file my_machdep.ml looking like that:
let my_machdep = {
Cil_types.sizeof_short = 2;
sizeof_int = 2;
sizeof_long = 4;
(* ... See `cil_types.mli` for the complete list of fields to define *)
}
let () = File.new_machdep "my_machdep" my_machdep
You will then be able to launch Frama-C that way to use the new machdep:
frama-c -load-script my_machdep.ml -machdep my_machdep [normal options]
If you want to have the new machdep permanently available, you can make it a Frama-C plugin. For that, you need a Makefile of the following form:
FRAMAC_SHARE:=$(shell frama-c -print-share-path)
PLUGIN_NAME=Custom_machdep
PLUGIN_CMO=my_machdep
include $(FRAMAC_SHARE)/Makefile.dynamic
my_machdep must be the name of your .ml file. Be sure to choose a different name for PLUGIN_NAME. Then, create an empty Custom_machdep.mli file (touch Custom_machdep.mli should do the trick). Afterwards, make && make install should compile and install the plug-in so that it will be automatically loaded by Frama-C. You can verify this by launching frama-c -machdep help that should output my_machdep among the list of known machdeps.
UPDATE
If you are using some headers from Frama-C's standard library, you will also have to update $(frama-c -print-share-path)/libc/__fc_machdep.h in order to define appropriate macros (related to limits.h and stdint.h mostly).

GCC declarations: typedef __pid_t pid_t?

I am confused about the declaration of (for example) pid_t. What does __pid_t mean? Is it another type defined elsewhere? If yes, where? Why is my types.h in ubuntu 13.04 64bit defining pid_t like:
#ifndef __pid_t_defined
typedef __pid_t pid_t;
#define __pid_t_defined
#endif
and not something like
typedef int pid_t;
I saw some websites that have types.h headers with the declaration done the last way. This is one:
http://www.sde.cs.titech.ac.jp/~gondow/dwarf2-xml/HTML-rxref/app/gcc-3.3.2/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/include/sys/types.h.html
UPDATE:
Ok I found out that a pid_t is an __pid_t which is an __PID_T_TYPE which is which is an __S32_TYPE which is an int. My question now is why is this? POSIX only states that pid_t has to be a signed integer, so why make the declaration enter soo deep in header files?
If you are pulling up your types.h via 'man types' then at the top of the header file(under description in the man page) there should exist an include file that defines '__pid_t' at some point as a signed integer(if Ubuntu claims that their types are POSIX compliant; otherwise pid_t could be anything). The symbol ' __' is considered reserved(C standard, dunno about C++). If I had to take a wild guess as to why pid_t is defined as __pid_t and not some int is because __pid_t is what Debian's or the Linux Kernel's developers decided to use for the process ID variable name in all of their library functions; therefore only '__pid_t' needs to be changed to change the integer size for a process ID.
You should really look around before asking a question, similar stackoverflow questions are easily found: Size of pid_t, uid_t, gid_t on Linux .
Ok I found what the __pid_t means on the answer to this question:
Why PID of a process is represented by opaque data type?
QUOTE
typedef __pid_t pid_t;
...
# define __STD_TYPE typedef
__STD_TYPE __PID_T_TYPE __pid_t; /* Type of process identifications. */
...
#define __PID_T_TYPE __S32_TYPE
...
#define __S32_TYPE int
UNQUOTE
So pid_t is an __pid_t which is an __PID_T_TYPE which is which is an __S32_TYPE which is an int.

how to use execlp to locate command in unix

In my program user will type the command and its arguments and I want to locate it. For example he prints wc -l -c. Since I don't know how many argument he will enter, how should I use execlp?
the syntax for execlp is
int execlp(const char*file,const char *arg0...,(char*)0);
Assume that I store command and its arguments in
char* arguments[].
Since feature requests to mark a comment as an answer remain declined, I copy the above solution here.
You want execvp(). – FatalError

Using sqlite from vala without dependence on glib

I need to use the Sqlite vapi without any depedence on GLib. SQlite is non-gobject library, so it should be possible to do that.
However, when I try to compile the following file with the --profile posix
option,
using Sqlite;
void main() {
stdout.printf("Hello, World!");
}
I get am error messages:
sqlite3.vapi:357.56-357.59: error: The symbol `GLib' could not be found
public int bind_blob (int index, void* value, int n,
GLib.DestroyNotify destroy_notify);
^^^^
sqlite3.vapi:362.68-362.71: error: The symbol `GLib' could not be found
public int bind_text (int index, owned string value, int n = -1,
GLib.DestroyNotify destroy_notify = GLib.g_free);
^^^^
sqlite3.vapi:411.42-411.45: error: The symbol `GLib' could not be found
public void result_blob (uint8[] data, GLib.DestroyNotify?
destroy_notify = GLib.g_free);
^^^^
sqlite3.vapi:420.59-420.62: error: The symbol `GLib' could not be found
public void result_text (string value, int length = -1,
GLib.DestroyNotify? destroy_notify = GLib.g_free);
^^^^
Compilation failed: 4 error(s), 0 warning(s)
It seems that several of the functions defined in the sqlite vapi make references to the GLib.g_free and GLib.DestroyNotify symbols. Are there any posix alternatives to those?
That should be fairly simple to solve, and I can imagine several solutions.
It boils down to declaring a different delegate void DestroyNotify (void* data) (either in the posix.vapi or sqlite3.vapi) and bind free() in posix.vapi.
The problem is the namespace, and you might need to file a bug and discuss it with the developers. If you want to avoid this problem and are ready to go with a workaround, just create a mini glib.vapi GLib namespace, where you bind only the DestroyNotify() and g_free() (binding to libc/posix free).
I would think that sqlite3 should not use GLib, but rather libc/posix, so you should be fine by modifying only posix.vapi and sqlite3.vapi and filing a bug with your patch (awesome, a contrib!).
Note that classes are unavailable under the POSIX profile, as Vala requires a support library (i.e. GLib, Dova) to support those features. Jürg Billeter has acknowledged that support for the POSIX profile is experimental and limited:
https://bugzilla.gnome.org/show_bug.cgi?id=618348
The only way you have is re-writing the sqlite VAPI (or just the classes/methods you need) making them posix friendly (but I guess you can't use classes in that way).
if the vapi for sqlite depends on glib you could just write your own or use the sqlite c code with c and just make some extern statements for the functions you need. for example i made a tool wich mixes vala and c for linux pure c for win32 and objective c and c for mac
https://github.com/boscowitch/wadoku-notify
i just added the 2 functions i need at the beginning of my vala app like this:
extern void init_db(char * path,bool mm);
extern void lookup(char * str);
i added the whole sqlite source cause i needed to activate full text indexing and change a bit in the code and in the beginning of vala there was no sqlite vapi

Resources