I'm using IDA Pro and right at the top of file is a field labelled Imagebase. Would this address be a absolute virtual address or relative virtual address or something else ?
0x0000000140001000
I think I found the answer I was looking for as written in the following article here It says "In PE file format, Image base address is used for binary virtual address itself." Meaning it is not considered a absolute virtual address.
Related
Let's say I have a file share at \\cloud\MyShare that is mapped to J:\Mason on my computer. If I have two filenames, \\cloud\MyShare\MyFolder\MyFile.dat and J:\Mason\MyFolder\MyFile.dat, is there any RTL or WinAPI routine for my code to establish that these two are in fact referring to the same file?
I have this logical location: |project://testProject/src/style.css| which I would like to convert to its related physical location. The location is first passed on to a Java file, where I try to convert it using the URIResolverRegistry.getInstance().logicalToPhysical(theLoc); method. The only problem is that it returns the exact location I passed it (the logical location). So it does not get converted. How come? Am I missing something? Or is there maybe another way to solve this?
Actually, project is supposed to be a "physical" URI already. If you want to convert it to an absolute path on the file system, then this is not supported directly.
However, if you are in an Eclipse context and you are free to depend on it, then rascal-eclipse offers this API:
IFile file = new ProjectURIResolver().resolveFile(myLoc);
String absolutePath = file.getLocation().toOSString();
This should be pretty simple I need know what dots mean in a url such as "../../../Program Files (x86)/Filed/examples/tmw_desert_spacing.png"
I'm assuming this is some kind of shorthand that means "the same as the current directory"/etc/folder/file.png a link to an article that explains this would be nice too, my google search turned up nothing since im not even sure this is called a url. thanks
more info: the program im writing won't except this as the file name, I need to konw what need to change to become acceptable.
According to RFC 3986:
The path segments "." and "..", also known as dot-segments, are
defined for relative reference within the path name hierarchy. They
are intended for use at the beginning of a relative-path reference
(Section 4.2) to indicate relative position within the hierarchical
tree of names.
The takeaway is that they have the same meaning as in paths on a linux or windows system - single dot means "the directory specified by the preceding part of the path", two dots mean "the parent directory of the directory specified by the preceding part of
I'm trying to run the readwrite example in the dsplink on the beagleboard. To do so, I need to give the dsp address as a command line parameter. How do I know what is the dsp address?
I have the config file of OMAP5030. Here's a snapshot of the dsplink memory section diagram (copied from CFG_OMAP3530_SHMEM.c):
If you must use readwrite, see this. You will want to look at .tcf files or such. However, as mentioned by TI engineers, readwrite is a very dangerous example to use. Look to MSGQ or other examples like that.
I write a C program gets in an environment variable's name and print out it's memory address, simply use the getenv() function to do the job. Let's say I wanna have the address location of PATH --> ./test PATH. But when I debug that program in gdb, the memory location of that variable is different. Can you explain in detail why is there such a different?
To be more exact:
./test PATH --> 0xbffffd96
debug in gdb --> 0xbffffd53
[edit] Thanks for your explanations. What I actually in question about is, how the memory address of a variable (in this case, an environment variable) changes with different programs. For example, I have 2 program a.out and b.out
./a.out --> PATH's address is some number
./b.out --> another number
So, what causes this difference between 2 numbers? I hope I have clearly demonstrated what I want to ask. Thanks mates.
Typically, environment variables are part of some "process data block", and those are inherited from the starting process. If you are running a program in a debugger, that debugger will have its own process data block and your program will inherit its process data block from the debugger. That in turn might have inherited the program data block of the IDE.
This doesn't matter anyway, because the interface to the environment variables doesn't give you that kind of details. For instance, on Windows it's quite likely that the environment variables will be converted from Unicode to your local 8 bit codepage when you ask for them. You'd never see the original variable, just (an approximation of) its value.
Perhaps you want to do?
printf("%s",getenv("PATH"));
Getting the environment variable string does make sense.
But, the address where the system gives you the string, has no relevance anywhere
(particularly outside the scope of this program).
You should be interested in the environment string value rather than its address.
If you have any reason to use the address, please give that here.
For example,
echo $PATH
gives me,
/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin: ... etc
All my programmatic interest with PATH would be in its contents not any sort of address.
Why would you expect it to return the same memory location every time? getenv returns "a pointer to a string containing the value for the specified name." It is not specified which memory location the string is located at, nor whether that location will later be overwritten.