I'm trying to write a python interface to a shared library. The library has headers provided, and so I'd like to be able to used them as the cdef input.
I realise that I need to preprocess the headers before I load them into CFFI. However, the library headers have code something like this:
#define ONE 1
char something[250+ONE];
which comes out of the preprocessor (gcc -E) as
char something[250+1];
CFFI complains that the 251 is not a simple numerical constant (which as far as parsing is concerned, is true). Is there a way to make GCC evaluate these integer constants at preprocessor time?
(Of course, I realise I can just manually change the header file, but I'd like to see if I can use the header files that are shipped with the library)
Related
I trying to debug a the yacc generated component for awk (awk.g.c) but when I define YYDEBUG it includes y.debug which I don't seem to have.
Where does y.debug come from?
Without it there are several references that are undefined.
I'm compiling the old 32v or V7 version of awk so I'm not sure if this is something that still exists.
Some versions of yacc (in particular, the AT&T version, still available as part of Plan 9) generated an additional file with the suffix .debug containing debugging information, notably the table which translated symbol numbers back into names. Modern yacc-alikes just insert this information into the generated C file, on the grounds that the memory consumption is basically trivial these days.
The name table might not be generated if you don't request it, but the way you ask for it depends on the yacc version:
Most bison versions only generate the table if the trace option is enabled. (Posix mandates -t for this, but bison provides a host of alternatives and not all historical yaccs complied.)
As indicated above, some really old yaccs put the name table into y.debug. The AT&T implementation, as I mentioned above, always did this, but guarded the #include line with a preprocessor conditional on YY_DEBUG
However, the yacc implementation you pointed to in a comment, which uses the conditionally-included y.debug mechanism, only generates the y.debug file if you invoke it with the -D flag. So that's what you need to do.
Background notes
I unearthed the information in point 3 from the V10 source linked in a comment. The download link is at the top of this page; that wasn't immediately obvious from the link in the comment. (That's the complete source tarball, which is about 70MB. The individual files linked to by the link in the comment have been HTMLised, which makes them a pain to work with.) I could have saved myself some time by reading the release notes (called yaccnews rather than CHANGES). The last note in that file describes the implementation, and I include the paragraph here since it has all the details on how debugging works in this particular yacc version.
8/11/81
Debugging changed. If the parser starts with %{#define YYDEBUG %} and yacc is invoked as yacc -D (for Debugging), then the parser uses an external variable named yydebug to control debugging output. If yydebug == 1, the parser prints out the text of the reduction when it performs one. If yydebug == 2, the parser also prints out the name of the token returned by each call to yylex, and if yydebug == 3, the parser also prints out the active items each time it changes state (this is uninteresting).
For what it's worth, it should be possible to generate a working, compilable parser using a modern yacc (such as bison or byacc). In the long run, that will probably be easier. (If you use bison and you require legacy yacc compatibility, you can use the -y flag. That flag is not supported by byacc, which claims to be legacy compatible regardless.)
I'm using GCC for and specific MCU target (to be accurate for AVR) I have a special external memory that I try to define a custom Section by using following command in linker options
-Wl,--section-start=.customsection=0x821000
and then using attribute inside the code just like this:
unsigned char X __attribute__((section (".customsection")));
everything is correct and works fine. But how can I define some limitation to this custom section that force the GCC linker to raise an error in case of overrun? By limitation I mean a way to define length of the section or end-address.
AFAIK, you can only specify the length in a linker file.
You would have to copy the linker file for your MCU and modify it.
For more information and examples see:
- https://www.avrfreaks.net/forum/create-new-section-ram
- https://www.avrfreaks.net/forum/custom-linker-script-atmega
I was told to post compiling questions on stackoverflow so this is the same question I've posted to Ubuntu Ask!:
I'm trying to compile a program that came with a Makefile. The makefile uses f77 and it seems that the programs call several f95 intrinsics. When I try to compile I get:
plotkit.a(userid.o): In function userid_':
fort77-5163-1.c:(.text+0x13e): undefined reference togetgid_' fort77-5163-1.c:(.text+0x234): undefined reference to `getuid_' collect2: error: ld returned 1 exit status
I also get the same error with fdate on another program in this distribution. I've tried to change the makefile to use different compilers such as gfortran) and they all cause MORE errors.
My question is how do I get getgid, getuid, and fdate to work with a f77 program? I'm additionally confused because there are getgid and getuid man pages but no installation on ubuntu?
I have a 64 bit 14.04 LTS installation.
Thanks for any ideas.
By default, gfortran (and other Fortran compilers) mangle procedure names by adding an underscore. When you reference getgid in source, the compiler changes that to getgid_. If the function getgid isn't defined in Fortran source, e.g. in C, then this will cause link errors such as the one you are encountering.
The functions getgid, getuid, etc are not Fortran functions, they are standard C library functions. If the code you are using is from somewhere else, look and see if the provided Makefiles have options listed to disable default underscoring by Fortran. For gfortran, this option is -fno-underscoring. Append this to the compiler flags used for the Fortran compiler in the makefile. For other Fortran compilers, consult their documentation for similar options.
If you aren't restricted to F77 and can make use of modern Fortran features, the other option is to fix this by providing interoperable interfaces for C library functions. e.g.
interface
function getgid() bind(C,name='getgid')
use iso_c_binding
implicit none
integer(c_int32_t) :: getgid
end function getgid
end interface
This will define an explicit interface for the C library function getgid so that you can call it from a modern Fortran implementation. You would define interfaces like this for each of the C library functions you need to call.
* As an aside, while the above interface works and is portable from a modern Fortran perspective, it isn't 100% portable from a C library perspective. The GNU implementation of getgid returns the type gid_t which though a long chain of typedefs is finally related to a true type in the files /usr/include/bits/types.h and /usr/include/bits/typesizes.h as an unsigned 32 bit integer. Fortran doesn't have unsigned types so while the storage sizes will match, if these functions ever return values above around 2 billion, they will be misinterpreted in Fortran as negative values. Also, since the storage type of gid_t is defined in the "bits" C header tree, they are potentially non-portable (not sure if the storage size is specified in POSIX or some other standard or implementation dependent).
The motivation is that I want to tell the compiler that my float *U array is 64 bytes aligned so that the compiler can do the vectorizations.
If using Intel compiler, I can use the __assume_aligned(U,64);I googled and found that if I want to do the same thing using GCC, I have to define another float *U_tmp=__builtin_assume_aligned(U,64), and use U_tmp. However, when it goes to compilation with GCC, the compiler reports that
"error: ‘__builtin_assume_aligned’ was not declared in this scope"
I don't know if I have missed some libraries or header files containing this GCC built in function.
This is supposed to work out of the box, without any additional headers. However, this has been added only to GCC 4.7, maybe your compiler is older than that?
I am writing a program which encrypt/decrypts itself in memory and then writes the .text memory region to a copy of the executable so I can change the encryption key each time.
This is mainly for a challenge as I am not great with C, and I'm incorporating parts in assembly as well.
My system is x86_64 Linux but I'm compiling with -m32
I am also using -nostartfiles (with gcc) so that I can write my own _start function. This function is written in assembly and this decrypts/encrypts the rest of the .text section. My problem is that the external functions are being compiled in the wrong order, such that when I try to dump the memory after it has been encrypted it calls an encrypted function which therefore doesn't work.
This is the current order of the functions:
some from -static
my functions which are in the correct order (assembly functions and then the ones from the main C file)
some more from -static
This doesn't work becuase the assembly encrypts from the main C file 'downwards', also encrypting some -static functions which are needed from the assembly functions.
This is the order I would like the functions to be in:
all -static functions & anything from an #include <>
functions from the .S assembly file (the whole .S in order)
functions from the .c main file (the whole .c in order)
any non-standard includes for the .c main file (ie not stdio.h etc, things from #include "")
Is there any way, short of manually mangling the ELF file, for me to reorder these functions so that the functions I need are not encrypted while the ones I want encrypted can be easily?
edit upon compiling with the musl (alternative libc) I can get all of my functions at the start, and the rest of the static functions following. However, This is the wrong way around still.
The "wrong" order of functions inside the binary comes from optimization efforts of the compiler. Functions that are used often (or often together) are near each other, so that no pagefault is generated by calling them.
You can turn off part of these optimizations with the flag -fno-toplevel-reorder. You can also use the attribute section to order only a subset of functions together (eg to encrypt them) or you can write your own linker scripts.
See also this question.