Instead of using 'setKernelArg' for passing the parameter to the kernel function, can we use extern??
for example:
cl_mem countMobj; //device variable
Suppose I have to pass this variable to the kernel function. Can I declare storage class specifier extern to pass the address instead of passing by 'setKernelArg'??
No. The host C/C++ compiler does not know that something like an OpenCL device with its own address space exists.
Related
The task I'm working on is to add support for the create_function interface to Crystal's SQLite binding: https://github.com/crystal-lang/crystal-sqlite3/issues/61
To access the parameters for a user-defined function, I need to access a C-style array (that is, a pointer to contiguous instances) of the sqlite3_value type, which if I'm not mistaken requires knowing the size of the type. But as far as I have found, there is no way to declare a Crystal type as an alias for a type defined in the C library.
Because it's a pointer, no, you don't necessarily need to know its layout. For opaque pointers this pattern is common in Crystal:
type Sqlite3Context = Void*
type Sqlite3Value = Void*
fun sqlite3_create_function(
[...]
xFunc : (Sqlite3Context, Int, Sqlite3Value*) ->,
[...]
)
It seems that when we dlopen() some libraries, they will be loaded into some preferred (but not fixed) addresses. I've checked the source code of dlopen(), and a core function says
static __always_inline const char *
_dl_map_segments (struct link_map *l, int fd,
const ElfW(Ehdr) *header, int type,
const struct loadcmd loadcmds[], size_t nloadcmds,
const size_t maplength, bool has_holes,
struct link_map *loader)
{
const struct loadcmd *c = loadcmds;
if (__glibc_likely (type == ET_DYN))
{
/* This is a position-independent shared object. We can let the
kernel map it anywhere it likes, but we must have space for all
the segments in their specified positions relative to the first.
So we map the first segment without MAP_FIXED, but with its
extent increased to cover all the segments. Then we remove
access from excess portion, and there is known sufficient space
there to remap from the later segments.
As a refinement, sometimes we have an address that we would
prefer to map such objects at; but this is only a preference,
the OS can do whatever it likes. */
ElfW(Addr) mappref
= (ELF_PREFERRED_ADDRESS (loader, maplength,
c->mapstart & GLRO(dl_use_load_bias))
- MAP_BASE_ADDR (l));
/* Remember which part of the address space this object uses. */
l->l_map_start = (ElfW(Addr)) __mmap ((void *) mappref, maplength,
c->prot,
MAP_COPY|MAP_FILE,
fd, c->mapoff);
if (__glibc_unlikely ((void *) l->l_map_start == MAP_FAILED))
return DL_MAP_SEGMENTS_ERROR_MAP_SEGMENT;
...
}
The comment says you can specify a preferred address, but OS will determine whether to use it.
Question
Is there any way we can specify the base address for each dlopened module?
ELF_PREFERRED_ADDRESSS is set to 0 by default, but this macro seems to infer that the preferred addresses can be changed, say by an environment variable? But even there is one, I doubt that it can be changed for each dlopened library.
If I want to implement this feature myself, it seems that I need to wrap a new dlopen function and pass the preferred address to the above core function (and use MAP_FIXED maybe). Is it correct?
Thanks!
Is there any way we can specify the base address for each dlopened module?
No.
ELF_PREFERRED_ADDRESSS is set to 0 by default, but this macro seems to infer that the preferred addresses can be changed, say by an environment variable? But even there is one, I doubt that it can be changed for each dlopened library.
This code is compiled into the dynamic loader ld-linux.so and can not be changed after the compilation.
If I want to implement this feature myself, it seems that I need to wrap a new dlopen function and pass the preferred address to the above core function (and use MAP_FIXED maybe). Is it correct?
The function is private to ld-linux. You will not be able to wrap it, or call it from outside of ld-linux.
P.S. What you are likely looking for is the prelink command.
How do you declare a pointer on a 16 bit Renesas RL78 microcontroller using IAR's EWB RL78 compiler to a register which has a 20 bit address?
Ex:
static int *ptr = (int *)0xF1000;
The above does not work because pointers are 16 bit addresses.
If the register in question is an on-chip peripheral, then it is likely that your toolchain already includes a processor header with all registers declared, in which case you should use that. If for some reason you cannot or do not wish to do that, then you could at least look at that to see how it declares such registers.
In any event you should at least declare the address volatile since it is not a regular memory location and may change beyond the control and knowledge of your code as part of the normal peripheral behaviour. Moreover you should use explicit sized data types and it is unlikely that this register is signed.
#include <stdint.h>
...
static volatile uint16_t* ptr = (uint16_t*)0xF1000u ;
Added following clarification of target architecture:
The IAR RL78 compiler supports two data models - near and far. From the IAR compiler manual:
● The Near data model can access data in the highest 64 Kbytes of data
memory
● The Far data model can address data in the entire 1 Mbytes of
data memory.
The near model is the default. The far model may be set using the compiler option: --data_model=far; this will globally change the pointer type to allow 20 bit addressing (pointers are 3 bytes long in this case).
Even without specifying the data model globally it is possible to override the default pointer type by explicitly specifying the pointer type using the keywords __near and __far. So in the example in the question the correct declaration would be:
static volatile uint16_t __far* ptr = (uint16_t*)0xF1000u ;
Note the position of the __far keyword is critical. Its position can be used to declare a pointer to far memory, or a pointer in far memory (or you can even declare both to and in far memory).
On an RL78, 0xF1000 in fact refers to the start of data flash rather then a register as stated in the question. Typically a pointer to a register would not be subject to alteration (which would mean it referred to a different register), so might reasonably be declared const:
static volatile uint16_t __far* const ptr = (uint16_t*)0xF1000u ;
Similarly to __far the position of const is critical to the semantics. The above prevents ptr from being modified but allows what ptr refers to to be modified. Being flash memory, this may not always be desirable or possible, so it is possible that it could reasonably be declared a const pointer to a const value.
Note that for RL78 Special Function Registers (SFR) the IAR compiler has a keyword __sfr specifically for addressing registers in the area 0xFFF00-0xFFFFF:
Example:
#pragma location=0xFFF20
__no_init volatile uint8_t __sfr PORT1; // PORT1 is located at address 0xFFF20
Alternative syntax using IAR specfic compiler extension:
__no_init volatile uint8_t __sfr PORT1 # 0xFFF20 ;
I'd like to be able to read from an arbitrary R connection (in the sense of ?connections), which would be passed to an R function by the user and then down into some C code via .Call.
The R API, in file R_ext/Connections.h, specifies a function, R_ReadConnection, which takes a pointer to an Rconn struct as its first argument, and does what I want. The struct itself is also defined in that header, but I see no way of retrieving a struct of that type, aside from getConnection (the C function), which is not part of the API. As far as I can tell, the external pointer associated with the connection also does not point to the struct directly.
So, could anyone please tell me whether there is a supported way to convert a suitable SEXP to a pointer to the associated Rconn struct?
Thanks in advance.
The R API function R_GetConnection() was added in R 3.3.0. It performs the conversion from SEXP to pointer to Rconn (a.k.a. Rconnection). Hence, the solution is now
#include <R_ext/Connections.h>
SEXP myfunction (SEXP conn_)
{
Rconnection conn = R_GetConnection(conn_);
// Do something with the connection
return R_NilValue;
}
This was documented in NEWS:
R_GetConnection() which allows packages implementing connections
to convert R connection objects to Rconnection handles. Code
which previously used the low-level R-internal getConnection()
entry point should switch.
I don't think there is (this is an oversight, I think). The workaround is to declare an appropriate prototype and use it
Rconnection getConnection(int n);
SEXP connect_me(SEXP conn) {
getConnection(INTEGER(conn)[0]);
return R_NilValue;
}
When I use the following statement,
typedef QPair<ItemA, ItemB> test
where ItemB is a smart pointer.ie typedef QSharedpointer<Z> ItemB
When I instantiate test, should I provide initialization values ?
eg: test Inst1(0,0);
Or does QPair automatically provide default constructed values?
I have found the Qt documentation to be very reliable in such low-level matters. And according to the QPair documentation, QPair has a default constructor with no arguments. (Alternatively, you could just have tried it out...)