Why are the virtual addresses in the dumpfiles different, when I use XDD and Radare2?
Radare2-dump
Xdd-dump
The first image shows the Radare2-dump, the second one the xdd-dump. The addresses are not completely different.
The xdd is:
000007b0
The radare2 is:
0x004007b0
Why is there a offset of 0x00400000?
Edit: I am working on Linux.
Related
I've been exploring the ADAM 6717 from Advantech.
This is the ModBus address table for said device:
At first I wanted to modify the value of the Digital output channel 0(DO0), so, as can be seen from the picture above, such address is the 0x0017.
I succeed at this by using a ModBus tool and the following settings:
Sending either "On" or "Off", turns On and off a LED connected to that output. Everything runs smoothly according to my expectation up to this point.
The problem arises when I want to read the Analog Input channel 6 or equivalently, address 400431~40044.
Since that address lies on the Analog Output Holding Registers part of the address table, I though that the following settings would accomplish the job:
However, as can be seen above, the reading shows 0.0 when there is actually 6V connected to that input (a potentiometer)
It is worth mentioning that I've made sure to enable the AI6 channel as well as setting it to Voltage mode instead of current. Also, the web utility for the device shows the AI6 reading correctly as I change the potentiometer's resistance value.
So the problem doesn't lie in the connection from the potentiometer to the AI6 but somewhere else.
Out of nothing and leaving aside what I think I know on this topic, I though of changing the function from 0x03 to 0x04
However, the response is exactly the same.
It bugs me that I can read and write values to the output coils but not the Analog output holding registers.
Is there any configuration that I might be missing over here?
Thanks in advance.
Device settings:
IP address: 10.0.0.1
Port in which the ModBus service is running: 5020
I'm fiddling around with creation of virtual MIDI ports in AudioKit (v5-main).
It seems to me that there is a confusion on INPUT and OUTPUT ports, but then again, perhaps I'm not understanding what's going on.
I create Virtual MIDI Input and Output ports by:
let midi = MIDI()
midi.createVirtualInputPorts(numberOfPort: 1, [Int32(1000000)], names: ["MIDI Test Input Port"])
midi.createVirtualOutputPorts(numberOfPort: 1, [Int32(2000000)], names: ["MIDI Test Output Port"])
I do realise that I can do this in one go (createVirtualPorts), but I wanted control over the portIDs for further investigation.
But when I list my INPUT ports by displaying:
midi.inputUIDs
The OUTPUT (portID 2000000) shows up on the list.
And vice versa, if I use:
midi.destinationUIDs
... I see the INPUT (PortID 1000000).
To me, it would make sense if my virtual Input Port showed up on the Input (inputUIDs) list, and the Output port showed up on the Output (destinationUIDs) list. But it's the other way round.
Further investigating my problem, I tried to inspect the receivedMIDINoteOn to see the portID reported.
The port UID for incoming MIDI events is the OUTPUT (PortID 2000000).
I double checked to see how physical MIDI ports behave, and indeed, I receive MIDI notes on INPUT ports, as expected.
Am I missing something with regards to terminology here (Input/Output/Destination)?
if mmap() was used to read a file, how can I find the number of data mapped by mmap().
float *map = (float *)mmap(NULL, FILESIZE, PROT_READ, MAP_SHARED, fd, 0);
The mmap system call does not read data. It just maps the data in your virtual address space (by indirectly configuring your MMU), and that virtual address space is changed by a successful mmap. Later, your program will read that data (or not). In your example, your program might later read map[356] if mmap has succeeded (and you should test against its failure).
Read carefully the documentation of mmap(2). The second argument (in your code, FILESIZE) defines the size of the mapping (in bytes). You might check that it is a multiple of sizeof(float) and divide it by sizeof(float) to get the number of elements in map that are meaningful and obtained from the file. The size of the mapping is rounded up to a multiple of pages. The man page of mmap(2) says:
A file is mapped in multiples of the page size. For a file that is
not a multiple of the page size, the remaining memory is zeroed when
mapped, and writes to that region are not written out to the file.
Data is mapped in pages. A page is usually 4096 bytes. Read more about paging.
The page size is returned by getpagesize(2) or by sysconf(3) with _SC_PAGESIZE (which usually gives 4096).
Consider reading some book like Operating Systems: Three Easy Pieces (freely downloadable) to understand how virtual memory works and what is a memory mapped file.
On Linux, the /proc/ filesystem (see proc(5)) is very useful to understand the virtual address space of some process: try cat /proc/$$/maps in your terminal, and read more to understand its output. For a process of pid 1234, try also cat /proc/1234/maps
From inside your process, you could even read sequentially the /proc/self/maps pseudo-file to understand its virtual address space, like here.
Recently I'm learning about the OS. And I want to write a simple bootloader, which change the real mode to protect mode and then load the simple kernel.
But I can't figure out the entry address problem.
At first I put the bootloader in the first sector of the OS.img(qemu), and then the kernel begin at the second sector.
Here's readelf result of my kernel:
The entry point address is 0x800c.
And the LMA and VMA are below:
A part of the bootloader which read elf-type kernel and then get into the entry(),which is the entry point address.
However, when I disassemble the bootloader, the entry() is below:
Call *0x8018, not *0x800c.
I don't know why this happen.
Could you please help me?
call *0x8018 performs a call to an address that is stored at 0x8018, that's correct since ELFHDR is 0x8000 and offset of e_entry in the header is 0x18.
The real problem is in the way you load segments into memory. Each segment should be loaded at address p_vaddr from file offset p_offset. Notice that in your case p_vaddr is 0x8000, that the same place in memory you loaded elf header to and that's why ELFHDR->e_entry gets overwritten. The easiest solution would be to load elf header at different address.
Source: http://www.skyfree.org/linux/references/ELF_Format.pdf
I suddenly just thought of this and got stuck deciding which data type should I use to store an IP Address?
I have thought of NSString; But if I would need the last digit for identifications, should I use float or double? And that is also another problem, since when can float or double have more than 1 decimal point?
I am probably asking the question wrongly, because I really don't know how to ask this.
The IP Address comes from an XML format <IP>192.168.1.1</IP>. Any idea how I should do this?
Use NSString. You are not going to do arithmetic with it. If you need the separate components you can use NSArray, but NSString will serve you well for just storing the IP address.
In response to your needs, you can always obtain the last character in your string using the NSString method:
NSString *lastCharacter = [ip_string substringFromIndex: [ip_string length] - 1];
Where ip_string is the string holding the IP address.
Edit in response to comment:
Logan's code is storing each element in the IP address separated by a period into an array. So if the IP address is 192.168.1.1, the array will equal (192, 168, 1, 1).
My code is storing the entire IP address in a string, and then obtaining the last character in that string. [ip_string substringFromIndex: [ip_string length] - 1] is just obtaining the last character in the string containing the IP address. The last character can be found at minus one character.
So if the IP address is 192.168.1.1, the lastCharacter string will just contain the number 1.
I suggested that code because you stated that you needed to do something with the last character in your IP address string, and my code shows how you can obtain the last character.
Use a string. You don't need to perform arithmetic on the IP do you?
It is typical to store IP addresses as strings, or arrays of integers. Another option is to store it as a 32 bit integer. It really comes down to what you want to do.
I would use NSString. If you need to get it piece by piece, use:
NSArray *pieces = [ipAddress componentsSeparatedByString: #"."];
192.168.1.1 is considered the default IP for numerous home high-speed wireless routers. It had been initially utilized by Linksys and yet has been seen used in a number of other home network products including some of those manufactured by Netgear and also Westell among others.
Even though IP address stands out as the default ip for a lot of high speed broadband wireless routers, this does not essentially has to be. A large number of producers set the default IP address to 192.168.1.1 as a way to market a standard precessing conditions and to make it simpler for very first time clients to setup their own networking systems simply and efficiently.
May only Linksys as well as other wireless routers operate using the 192.168.1.1 IP?
Certainly no, given that 192.168.1.1 is definitely a non-public IPv4 address, any type of laptop or computer, modem, switch, or another web system might be devised to work with this unique IP. Nonetheless, it's not in most cases advisable because there are lots of products which default to 192.168.1.1 which in turn interaction issues can occur soon after from many different products utilizing the same IP. It's also really important to consider that a single network equipment might have just one single Ip, if you own numerous units using private IP address, basically at least one has to be adjusted to an alternative location.