So I'm dealing with a fat binary, and I'm trying to find the method offset for frame [FOOClass abcdMethod].
Using otool I get the __text segment addr and offset. The only problem is that offset in decimal given in the output equals the starting address of the __text segment.
My question is. How can someone deduct the offset of the method in a 64bit environment?
otool or any Apple compiler tools accepts the argument -arch which specifies which part of the fat binary it'll look. See otool's man page, for example. nm might be useful, too.
But, why do you want to get the offset??? I guess you can ask what you want to do, which lead to this current question how you get the offset. Then people might come up with an easier way to achieve you originally wanted to do.
Related
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.
I'm using vkCmdDispatchIndirect, but I'd like to be able to specify non-zero base values, as you can with vkCmdDispatchBase. However, the struct VkDispatchIndirectCommand only has members for the number of workgroups, not base values.
The obvious answer is that you can't, but it seems odd to me that they'd provide the non-zero base functionality only in the non-indirect case, I figure I must be missing something.
You can't. Thanks for free 15 points :D
vkCmdDispatchBase was part of Device Groups extension, so the command was possibly only an afterthought.
If you think Indirect version should be in the API, the community here cannot help you. You need to petition Khronos at KhronosGroup/Vulkan-Docs.
I am an engeneer, not a code writer. (from France, so please excuse my sometimes poor english) So I lack basig knowledge, e.g. "gdb" :
A fortran program that I am developing segfaults at an openmp clause.
I'm given by gdb the address of the memory location that the program cannot reach, but I would like to know the NAME of the offending variable, to be helped in finding what goes wrong.
How can I be given the NAME of the variable located at 0x00002aaaaab455ca, gdb says in my precise case ?
Thank's,
David
I may need to have a gdb script give me all the adresses of all the variables, but I do not even know how to do that neither; could you give me an address where to learn that, please ? Thank you.
EDIT: I use gfortran this way :
$ gfortran input.f -g -freal-8-real-16 -o output
EDIT2: Excuse me, of course I DO use -fopenmp; and I also use all of the warnings in a preceding compilation, in order to have very "clean" code for the production runs. (I've checked whatever possible and I just need the NAME of the variable that segfaults, in order to correct the calculation of it's index)
could you give me an address where to learn that
Such questions are off-topic here, but here is a book on GDB.
You have two choices:
You can learn just enough GDB to debug this problem, or
You can bribe someone more familiar to do it for you.
Assuming you want to do (1), here are some of the commands you may find useful:
where (tells you where in the program you are crashing)
x/i $pc (tells you the instruction that caused the crash)
info registers (this, together with above, should give you the exact address that your program tried to access)
info locals, info globals, info addr 0x.... (gives you a list of local and global variables, and may also tell you what you need about the crashing address).
If above isn't enough, you should edit your question to show how far you got (i.e. the output from above commands), and we may be able to help you more. But it's hard to debug over such a low-speed connection, so you really should try to find someone closer to you (i.e. use option (2)).
Does anyone know where I can find documentation about the output of windbg command !ddls? I'm mostly interested in the meaning of the Flags and LoadCount parameters, and what does it mean when the value of LoadCount is 0xffffffff.
I spent a day searching for this information on the NET, but didn't find anything useful.
Thanks in advance,
Andre
This link should help - Is 0x0000ffff the default load count of a dll in windows?
Snip from the same The load count for a DLL is a 16-bit value. If that value, treated as a signed short, is -1 (0xfffff) it indicates the DLL is statically linked, otherwise it's dynamically loaded.
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.