What is POSIX function to get MTU Size value ??
Thanks.
No, there is no generic POSIX function for that.
The best you can do is to invoke a GET_MTU / SIOCGIFMTU ioctl on the socket, but this is not in the POSIX standard. not supported by all POSIX.
Related
Raku/Perl6, Windows 7 and 10
Does Raku's NativeCall run "LocalFree( )" after it creates buffers? Or do I need to do it myself?
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-localfree
Many thanks, -T
EDIT: this at JJ's request.
https://learn.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw
C++
LSTATUS RegSetValueExW(
HKEY hKey,
LPCWSTR lpValueName,
DWORD Reserved,
DWORD dwType,
const BYTE *lpData,
DWORD cbData
);
In assembly code:
lea eax,[##lMode]
call RegSetValueExA,HKEY_CURRENT_USER,offset
[##VAL_Type],0,REG_DWORD,eax,DWORD
"offset [##VAL_Type]" -> pointer to the keyvalue string buffer
"eax" -> pointer to the data (in the buffer "##lMode")
"*lpData" and "##lMode" are a buffers in an allocated space in memory. After their use, their memory needs to be given back to the system with "LocalFree".
So to rephrase my question, when NativeCall allocated space in memory for buffers, does it consequently give back the space after it is done with it, or does it just leave it there (memory leak)?
So, do I need to call "LocalFree()" or does NativeCall take care of it for me?
If you already understand that...
What NativeCall does is call C functions. It is not NativeCall's role to allocate or free memory.
LocalFree is a C function. The normal way to call a C function from Raku is via NativeCall.
...then you can safely ignore this answer -- and the question to which this is an answer, and Todd's answer.
If you are not confident about the above, then perhaps this answer will clear up any confusion and reduce the chances you're misled. What I write in the following is pendatic. But I feel it's appropriate to ensure clarity.
Does Raku's NativeCall run “LocalFree( )”?
Yes, if you tell it to.
NativeCall is the feature normally used to call C functions from Raku.1
Does Raku's NativeCall run "LocalFree( )" after it creates buffers?
NativeCall does not create buffers of its own accord. All NativeCall does is call C functions as instructed by users' code.
Let's say you use NativeCall to call a C function that creates a buffer. Does that mean NativeCall created the buffer? Or did you? (In a similar vein, if one uses NativeCall to call LocalFree after one has used NativeCall to call a C function that creates buffers, does that mean the answer to Todd's question is Yes? And if not, does that mean the answer is No?)
You can use NativeCall to call LocalFree because LocalFree is a C function, and calling C functions is precisely what NativeCall does when you use it to do something.2
Or do I need to do it myself?
Depending on your answer to the parenthesized questions a couple paragraphs above...
Given that NativeCall does not create buffers, you can't need to do anything related to NativeCall creating buffers.
In the alternative, if NativeCall creates buffers, then it's because you used it to manually call C functions that create buffers and you therefore also need to manually call C functions to free those buffers if you want them freed.
Footnotes
1 NativeCall is the Raku C FFI.
2 No matter what you "use" NativeCall for you would start with a use NativeCall statement. Then you would typically use it to call C functions. It's possible you might use it for access to nothing more than, say, some of the constants it defines.
NativeCall does not close any WinApi call buffers, so you need to do it yourself.
Under the Stream Programming Guide: Polling versus Run-Loop Scheduling section, the last para says:
It should be pointed out that neither the polling nor run-loop
scheduling approaches are airtight defenses against blocking. If the
NSInputStream hasBytesAvailable method or the NSOutputStream
hasSpaceAvailable method returns NO, it means in both cases that the
stream definitely has no available bytes or space. However, if either
of these methods returns YES, it can mean that there is available
bytes or space or that the only way to find out is to attempt a read
or a write operation (which could lead to a momentary block). The
NSStreamEventHasBytesAvailable and NSStreamEventHasSpaceAvailable
stream events have identical semantics.
So, it seems neither hasBytesAvailable/hasSpaceAvailable, nor stream events provide a guarantee against blocking. Is there any way to get guaranteed non-blocking behaviour with streams? I could create a background thread to get guaranteed non blocking behaviour, but I want to avoid doing that.
Also, I fail to understand why NSStream can't provide gauranteed non-blocking behaviour given that the low-level APIs (select, kqueue, etc.) can do so. Can someone explain why this is the case?
You either run your reading or writing in a different thread or you can't use NSStream. There are no other ways to get guaranteed non-blocking behavior.
For regular files and sockets you most likely will get non-blocking behavior if you schedule the stream on a runloop. But there are other types of stream that are not implemented on top of a file descriptor. By documenting the base class as not always non-blocking Apple keeps options open of implementing different streams in a way where they can't guarantee the non-blocking property.
But since we can't check the source code we can only speculate on this. You might want to file a bug with Apple requesting them to update the docs with that information.
This is what I'm referring to:
From what I've read, an objc_msgSend is essentially what is happening at the c level when you send an Objective-C message, and this setting set to Yes ensures that the message being sent has the same number of arguments as the the receiver is expecting.
Is this correct? Also what are the advantages and disadvantages to setting this to Yes or No? Should I only set this to Yes in development and No in production?
You are essentially correct, yes.
Apple sets it to Yes by default because it helps to find errors faster. The only reason to set it to No would be because you are compiling legacy code that hasn't been updated to compile cleanly with this option on.
"Enable Strict Checking of objc_msgSend Calls" is a compile time check, not run time, so there is no benefit to turning it off in production.
There's a presentation "What's new in LLVM" on Apple's website (text of the presentation is here).
It looks like the compiler will now (optionally) strictly check the types of calls to obj_msgSend. You will have use a correctly-typed function pointer in place of directly calling objc_msgSend.
Example given:
#include <objc/message.h>
void foo(void *object) {
typedef void (*send_type)(void *, SEL, int);
send_type func = (send_type)objc_msgSend;
func(object, sel_getUid("foo:"), 5);
}
I'd like to instrument syscall brk (and other calls but this in first order, it's most important to me) in given binary (preferably on actual syscall/sysenter level (x86-64 and x86) of making sys_brk call).
Main goal:
A part of sandbox which gives fixed amount of memory to jailed process
So, I'd like to get rid of brk system calls (and most preferably others in next order) and simulate memory allocations under fixed limit. Fixed limit is memory space, available to program. (You can think about it like making a kind of sandbox with fixed amount of available memory)
How to implement (one of) some example possible solutions (or yours solution):
just changing instructions to NOP
As brk returns 0 on success, simulate it's successes with setting operations that sets memory (register) state , as brk would be called with success.
More complex... instrument with code (or function call) which simulates success memory allocations under fixed limit.
Most flexible (maybe overkill in my case) to change this syscall into function call and add provided function to binary.
Given binary is code that can be malicious in one of two (most preferably both :) ) forms:
shared library - here I can setup environment before function call (for example do brk call in controlled way)
program binary - in this case we need to give program fixed amount of memory (by caller, or on begining of program "one syscall"), cause it can not allocate. Example of calling such program should be included in answer.
As problem is highly connected with many other aspects, I tried do my best in separating it as question, but please give me advice if I should specify something more or less.
Answers with implementation, links to resources (books, tutorials) are welcome.
(I am most interested in Linux, and solution that is reliable, so that people preparing binaries, even in assembler, would not have to worry about execution of their code)
LD_PRELOAD will trap C calls to brk(), but it won't trap the actual system call (int/syscall instruction). There's no portable way to trap those, but on Linux, ptrace will do it. Memory can also be allocated to a program by mmap(), so you'll need to intercept that call too.
Of course, what it seems you're really looking for is rlimit().
Yeah, I don't think you want valgrind for this.
You can use LD_PRELOAD or linker tricks to capture brk(2): see these other discussions:
Function interposition in Linux without dlsym
Overriding 'malloc' using the LD_PRELOAD mechanism
Code might look like this:
#include <unistd.h>
#include <dlfcn.h>
/* prototype int brk(void *addr); */
static int (*real_brk)(void *addr) = NULL;
int brk(void * addr) {
real_brk = dlsym(RTLD_NEXT, "brk");
if (real_brk == NULL) {
fprintf(stderr, "error mapping brk: %s\n", dlerror());
return -1;
}
printf("calling brk(2) for %p\n", addr);
return (real_brk (addr));
}`
and then LD_PRELOAD that to intercept brk(2)
I would like to use printf to diplay text on a serial port of an ARM microcontroller. I am unable to do so. Any help is appreciated.
My init_serial looks like this
void init_serial (void)
{
PINSEL0 = 0x00050000; /* Enable RXD1 TxD1 */
U1LCR = 0x00000083; /*8 bits, 1 Stop bit */
U1DLL = 0x000000C2; /*9600 Baud Rate #12MHz VPB Clock */
U1LCR = 0x00000003; /* DLAB=0*/
}
which is obviously wrong.
For microcontollers, you typically have to define your own putc function to send bytes to whichever UART you're using. print will then call your putc.
Check the documentation for the libraries supplied with your compiler.
Note that this is entirely unrelated to how you intialise your UART. All that matters is which UART you're using.
(On an unrelated issue, rather than saying:
PINSEL0 = 0x00050000; /* Enable RXD1 TxD1 */
U1LCR = 0x00000083; /*8 bits, 1 Stop bit */
there are typically #defines for registers which (usually) aid readability, provide a link to the bit names in the documentation, and reduce the need for comments to be added and maintained on every line like these. For example:
PINSEL0 = PICSEL0_RXD1EN | PICSEL0_TXD1EN;
U1LCR = U1LCR_8BITS | U1LCR_1STOPBIT;
..and so on.)
To make printf(), puts() etc work on an embedded platform, you need to implement some hooks that work with the C library. This is typically dependent on the C libraries provided with your compiler, so is probably compiler-dependent. But in many cases the library just requires you to provide a putc() function (or similar name), which takes a character (generated by the printf() library function) and sends it to your chosen output device. That could be a memory buffer, serial port, USB message, whatever.
From the point of view of the C library, the putc() function would be run-to-completion, so it's up to you whether you implement it to be a simple blocking function (waiting until the serial port is free and sending the character), or non-blocking (putting it into a buffer, to be sent by a background interrupt task; but the buffer might fill up if you output enough bytes fast enough, and then you have to either block or discard characters). You can also make it work properly with your RTOS if you have one, implementing a blocking write that sleeps on a semaphore until the serial port is available.
So, in summary, read the documentation for your compiler and its C library, and it should tell you what you need to do to make printf() work.
Example links for AVR micro with GCC compiler:
AVR libc stdio docs
a blog post
ARM GCC compiler using newlib C library:
Newlib C library docs
Defining host interface - syscalls - write() function
I'm not sure about ARM in particular...
For some chips, within the IDE, you need to specify that you need a heap to use the printf, and how big it should be. The programmer won't automatically put one on.
Check in the menus of your programmer/IDE and see if there is a place to specify the heap size.
And I agree with Steve, this is only if you can actually use the printf, otherwise write your own little snippet.