I am trying to make a dyld extractor similar to dyld_decache and dsc_extractor. But I am having trouble parsing the __objc_selrefs section.
For testing purposes I used libsystem_trace.dylib, and was able to find and parse its mach_header and its segments and sections. But looking at the __DATA.__objc_selrefs section I find pointers like 0x201b8647fc8 and 0x201b860d716, which are way too high and point outside the cache.
In contrast, in a normal Macho file, the pointers in the __objc_selrefs section point to their corresponding string in the __TEXT.__objc_methname section.
I know that dyld slides and rebases sections, but after a lot of tinkering, I still could not fix the pointers. Any guidance would be amazing, especially given how little resources there is out there.
These "addresses" don't just point outside the cache, they point outside the maximum range iOS allocates for the userland address space.
The thing is that these aren't raw addresses, they're addresses with some flags mixed into them. I've seen at least 0x20000000000 and 0x40000000000, and they seem to be exclusive to Objective-C code. I have no idea what they mean or what the true bitmask for these flags is, but so far keeping the lower 40 bits (0xffffffffff) of the addresses has done the job for me.
That would turn e.g. your 0x201b8647fc8 value into 0x1b8647fc8, which should be well inside the shared cache boundaries.
Related
I've encountered a problem with my gameproject lately. When I load more than a certain number of textures (around 1000) at startup I recieve an error regarding memory (because I have to use 32-bit in XNA). I am self-taught and so have only basic knowledge of the "correct" ways to program a game. The project itself is getting very big and although I try to compress images together etc, I will have to use more than 1000 textures throughout the project.
My question, then, is: How can I load textures at other points in time than at startup in XNA, using vb.net? (I'm not using classes at all that I'm aware of, so I hope to stay away from that if possible)
Thank's for any feedback on this!
/Christian
I cannot comment, so I'll just put my idea here. Declaration time: I am also self-taught developer, so the algorithm that I'm using isn't proven to be the standard or anything like that. Hope it helps!
I am using a single class called GContent witch is "instanciated" (more like loaded) the first thing when game starts. This class is static, and it has lists for all textures, sounds and spritefonts in game. So, anywhere in my code I can put GContent.Texture("texture_folder\\texture_name"); (similar for sound and spritefont). Now, before this function loads Texture2D, it checks it's list of textures, and tries to return a texture with the name that is asked for in parameter. If it finds the right texture, it returns the texture from the list. If not, it uses Content.Load(textureFullPath); (by full path I don't mean "C:\Users\....") to load the texture, give it a name (Texture2D.Name) equal to the parameter textureFullPath, adds that texture to the list, and then returns the new texture. So, the more you play my game, the more textures will be loaded, if I don't load all the assets at the start of the game. Now, I imagine you can simply have an array of strings that represent all textures that are used by a single level, or a map, or main menu... This way, you could easaly create function that will take List< string > and try to load or unload all textures of one map/level/menu...
So, my answer is pretty much: have a static class with lists of assets and load/unload asset(s) from where ever in game you want!
Also, if my answer helped you, please, check it as an answer :)
So the answer seems a lot easier than I expected, if I'm doing it right at the moment(?).
I simply Load the content needed for all "Worlds" in the beginning of the game (in the Protected Overrides Sub LoadContent()) and then Dispose() and Load.Content() depending on what World is loaded later (in any Sub I choose):
TextureName = Content.Load(Of Texture2D)("")
TextureName.Dispose()
If there isn't any problem I'm not yet aware of, this seem to do the trick and does not leave me with the memory error in the start.
Thank you Davor Mlinaric and Monset for helping me along
In c2 architecture specific file i see the above variable. Please share
1. what it is?
2. Whether does it has any relation to the run time constant pool.
Thank you.
An IR graph node that represents a base address of the compiled method's constants table in a machine-specific manner. This node actually does nothing on x86, since the architecture allows to reference the whole range of 32-bit or 64-bit addresses inline.
Generally, no. Though some constants from the constant pool (particularly, floating point) may appear in that table.
P.S. I guess HotSpot Compiler guys are too busy to browse StackOverflow :) The better place for asking C2 implementation-specific questions is hotspot-compiler-dev list.
When attached to the debugger via Xcode, LLDB provides a useful view of local variables (the bottom left of the screenshot):
I found an LLDB command frame variable (and gdb's info locals) that provides a list of the local variables (as seen in the right side of the screenshot above).
My hope is that this functionality is possible to perform on the device at runtime. For example, I can access the stack trace using backtrace_symbols(), the current selector via _cmd, and a few others.
Has anyone had experience in this area? Thanks in advance.
Xcode/LLDB can show you this information because they have access to debug information in the binary, called a symbol table, which help it understand what memory locations correspond to which names in your source code. This is all outside the Objective-C runtime, and there's no interface in the runtime to get at it.
There's another reason why this won't work, though. When you're building code to run in the debugger, compiler optimizations are turned off, so all the variables you reference in your code are there.
When you build for release, though, generally the compiler optimizations get in there and re-arrange all your carefully named local variables to make things run faster. They might not even ever get stored in memory, just in CPU registers. Or they might not exist at all, if the optimizer can prove to itself that it doesn't need them.
My advice is to think again about the larger problem you're trying to solve...
I want to develop a VGA graphics driver (for Linux(Ubuntu)) with support for the basic primitives such as putpixel, drawline, fillrect and bitblt. I want to do it in protected mode.
I´ve been googling for a week and the following four links are the best I have found:
http://www.brackeen....vga/basics.html
http://www.osdever.n...VGA/vga/vga.htm
http://bos.asmhacker...sing%20bios.htm
Unfortunately, the first one uses a BIOS call so I cannot use it. The second link has lots of information on the VGA registers but no examples showing how to make them work together. The third example is a example to switch in 13h mode but i've tried it and nothing happened. Can you guys give me a hint? Thanks in advance!
--Vincenzo
my code at http://bos.asmhackers.net/docs/vga_without_bios/snippet_5/vga.php
works fine if you are in 32bit mode with full hardware access. Unfortunately I doubt that any Linux variant will let you directly access the VGA ports. I'm not sure how you develop this driver, but if you made sure that you have full access to the VGA ports it should work. In my example code I only switch between mode 0x03 and 0x13, but in the folders above you'll be able to find port values for most other common VGA modes, as well as C code to do the switch if you prefer that.
Christoffer code include files are found BOS operating system source code like text.inc and font8x16.inc
http://bos.asmhackers.net/downloads.php
This is coming many many years later but I think it's still very relevant and if somebody is struggling I hope they can find it useful.
First of all, it is completely possible to configure VGA only using registers without interrupts, as hard as it may be. A useful resource about registers and how to configure them can be found here, but unless you have a ton of time to spare to learn how to properly do all of it, move to the following section.
If you wish to really learn how to do it, I suggest going through with the documentation provided earlier. However, some of it is already done!
Chris Giese did a great job demonstrating exactly how to do this for MS-DOS system, and while you may think that doesn't help you, it really does.
Chris's code can be found here. If you want another useful codes check here as well.
Now, while it only works for MS-DOS it's actually easy to convert to other systems. The code already contains all data needed to configure the registers in many different modes. And that's the part that saves you a ton of time going through documentation.
The code uses functions outportb, inportb, which are MS-DOS functions, to write/read single byte to/from a port. Therefore, you have to redefine these functions to read/write for your own system. Redefinition complexity depends on the system you operate on.
In addition, you will also need to provide means to write to physical memory region between 0xA0000-0xBFFFF which corresponds to standard VGA memory area. Once you have that allocated, you need to also redefine the functions pokeb pokew peekb which will help you output things (text or pixel data) on the screen.
One last note: the code is already defined to work with many different modes including both text and display modes.
Would it be possible to take the source code from a SNES emulator (or any other game system emulator for that matter) and a game ROM for the system, and somehow create a single self-contained executable that lets you play that particular ROM without needing either the individual rom or the emulator itself to play? Would it be difficult, assuming you've already got the rom and the emulator source code to work with?
It shouldn't be too difficult if you have the emulator source code. You can use a method that is often used to store images in c source files.
Basically, what you need to do is create a char * variable in a header file, and store the contents of the rom file in that variable. You may want to write a script to automate this for you.
Then, you will need to alter the source code so that instead of reading the rom in from a file, it uses the in memory version of the rom, stored in your variable and included from your header file.
It may require a little bit of work if you need to emulate file pointers and such, or you may be lucky and find that the rom loading function just loads the whole file in at once. In this case it would probably be as simple as replacing the file load function with a function to return your pointer.
However, be careful for licensing issues. If the emulator is licensed under the GPL, you may not be legally allowed to store a proprietary file in the executable, so it would be worth checking that, especially before you release / distribute it (if you plan to do so).
Yes, more than possible, been done many times. Google: static binary translation. Graham Toal has a good howto paper on the subject, should show up early in the hits. There may be some code out there I may have left some code out there.
Completely removing the rom may be a bit more work than you think, but not using an emulator, definitely possible. Actually, both requirements are possible and you may be surprised how many of the handheld console games or set top box games are translated and not emulated. Esp platforms like those from Nintendo where there isnt enough processing power to emulate in real time.
You need a good emulator as a reference and/or write your own emulator as a reference. Then you need to write a disassembler, then you have that disassembler generate C code (please dont try to translate directly to another target, I made that mistake once, C is portable and the compilers will take care of a lot of dead code elimination for you). So an instruction of a make believe instruction set might be:
add r0,r0,#2
And that may translate into:
//add r0,r0,#2
r0=r0+2;
do_zflag(r0);
do_nflag(r0);
It looks like the SNES is related to the 6502 which is what Asteroids used, which is the translation I have been working on off and on for a while now as a hobby. The emulator you are using is probably written and tuned for runtime performance and may be difficult at best to use as a reference and to check in lock step with the translated code. The 6502 is nice because compared to say the z80 there really are not that many instructions. As with any variable word length instruction set the disassembler is your first big hurdle. Do not think linearly, think execution order, think like an emulator, you cannot linearly translate instructions from zero to N or N down to zero. You have to follow all the possible execution paths, marking bytes in the rom as being the first byte of an instruction, and not the first byte of an instruction. Some bytes you can decode as data and if you choose mark those, otherwise assume all other bytes are data or fill. Figuring out what to do with this data to get rid of the rom is the problem with getting rid of the rom. Some code addresses data directly others use register indirect meaning at translation time you have no idea where that data is or how much of it there is. Once you have marked all the starting bytes for instructions then it is a trivial task to walk the rom from zero to N disassembling and or translating.
Good luck, enjoy, it is well worth the experience.