I'm working on bare metal Programming on the Beaglebone Black with a Segger J-link under Ubuntu linux with the arm-none-eabi toolchain.
So now i get every time the error No source aviailable for "0x...."
When I pause the bone I get following in the Disassembly:
b6e93ce1: inc %ebx
b6e93ce2: fdivl -0x4922eb40(%esi)
b6e93ce8: call 0xdfa019f7
b6e93ced: add %ch,%bl
b6e93cef: mov $0x50,%dh
b6e93cf1: add $0xdd,%al
b6e93cf3: mov $0xa4,%dh
b6e93cf5: or %ebp,%ebx
b6e93cf7: mov $0xcc,%dh
b6e93cf9: inc %eax
b6e93cfa: fnsave -0x4922bf2c(%esi)
b6e93d00: add %al,(%eax)
b6e93d02: add %al,(%eax)
b6e93d04: add %al,(%eax)
b6e93d06: add %al,(%eax)
b6e93d08: js 0xb6e93d4c
b6e93d0a: fnsave -0x4922bb54(%esi)
b6e93d10: xor $0x42,%al
b6e93d12: fnsave -0x4922cfc0(%esi)
b6e93d18: mov $0x42,%ah
b6e93d1a: fnsave -0x4922cf98(%esi)
b6e93d20: cmp $0x31,%al
b6e93d22: fnsave -0x4922b92c(%esi)
b6e93d28: xorb $0xdd,(%edx)
b6e93d2b: mov $0xe0,%dh
b6e93d2d: xor %ebx,%ebp
b6e93d2f: mov $0xf0,%dh
When I start debugging the programm the J-Link restarts the bone correct but then the linux starts and not my Programm.
You may have several problems here, but the most severe is that you are using a version of gdb targeted for Intel processors: ebx, esi and friends are Intel 32 bits registers.
You have to use arm-none-eabi-gdb, not the gdb that comes with Ubuntu.
An easy way to avoid confusion is to explicitly use arm-none-eabi-gcc, arm-none-eabi-as, arm-none-eabi-ld and friends in your scripts and make files.
J-Links comes with a gdb-server software that acts as an intermediary between GDB and the JTAG hardware. Once the gdb-server is running, you can start a debugging session, assuming you are using a version of GDB debugger that matches your target processor.
This is obviously not your case, since your disassembled code looks pretty much like x86 assembly language code. This makes me think you are using a GDB executable compiled for an x86 target. You therefore really do need to get a version of GDB compiled for use with ARM targets.
You will find a version suitable to your needs in the bin directory of a Linaro toolchain, either for Windows or Linux. Its name will be arm-none-eabi-gdb.exe (Windows) or arm-none-eabi-gdb (Linux).
Related
I have 2 types of ARDUINO-cards. ATMEGA 2560 and ATMEGA 328P.
In my Delphi7 (XP64 sp2) I have modified the JvHidDeviceController Unit to show the PID/VID's of the abovementioned Cards. That works perfectly. And with the use of the TComPort unit I can communicate with the selected card. No problems here.
And here is the problem:
I connect my AVR MARK II (usb-tiny). System "says" OK.
(When I run the ARUINO program I have no problems communicating with the connected card.)
I run the Delphi program (JVHidDeviceController Unit), the 2560 and 328p PID/VID appear in a LIST-box but NOT the AVR-MARK II.
I Wonder why ? Please help.
After a search on the WWW I discovered, that the UNO (328P) could be turned into a ISP programmer. And by doing so I solve 2 (sub-)problems. I got the code ("bootloader") and the UNO Stills responds to the JVHidDeviceController requests. (Final solution in reach.. ) Kris
I want my application to always run using the real gpu on nVidia Optimus laptops.
From "Enabling High Performance Graphics Rendering on Optimus Systems", (http://developer.download.nvidia.com/devzone/devcenter/gamegraphics/files/OptimusRenderingPolicies.pdf):
Global Variable NvOptimusEnablement (new in Driver Release 302)
Starting with the Release 302 drivers, application developers can
direct the Optimus driver at runtime to use the High Performance
Graphics to render any application–even those applications for which
there is no existing application profile. They can do this by
exporting a global variable named NvOptimusEnablement. The Optimus
driver looks for the existence and value of the export. Only the LSB
of the DWORD matters at this time. A value of 0x00000001 indicates
that rendering should be performed using High Performance Graphics. A
value of 0x00000000 indicates that this method should be ignored.
Example Usage:
extern "C" { _declspec(dllexport) DWORD NvOptimusEnablement = 0x00000001; }
The problem is that I want to do this using Delphi. From what I've read Delphi does not support export of variables even though some hacks exists. I did try a few of them but couldn't make it work.
In the same nvidia document I read that forcing the proper GPU can be accomplished via linking statically to one of a handful listed dlls. But I don't want to link to dlls I'm not using. (Why the opengl.dll is not one of them is beyond me.) A simple exported variable seems much cleaner.
From what I've read Delphi does not support export of variables.
That statement is incorrect. Here's the simplest example that shows how to export a global variable from a Delphi DLL:
library GlobalVarExport;
uses
Windows;
var
NvOptimusEnablement: DWORD;
exports
NvOptimusEnablement;
begin
NvOptimusEnablement := 1;
end.
I think your problem is that you wrote it like this:
library GlobalVarExport;
uses
Windows;
var
NvOptimusEnablement: DWORD=1;
exports
NvOptimusEnablement;
begin
end.
And that fails to compile with this error:
E2276 Identifier 'NvOptimusEnablement' cannot be exported
I don't understand why the compiler doesn't like the second version. It's probably a bug. But the workaround in the first version is just fine.
I'm not a Delphi expert, but AFAIK it is possible to link to static libraries implemented in C from Delphi. So I'd simply create a small stub library, just providing this export, which is statically linked into your Delphi program. This adds the very export you need.
This should be a very simple,very quick qustion. These are the first 3 lines of a program in C I wrote:
Dump of assembler code for function main:
0x0804844d <+0>: push ebp
0x0804844e <+1>: mov ebp,esp
0x08048450 <+3>: and esp,0xfffffff0
... ... ... ... ... ... ...
What is 0x0804844d and 0x0804844e and 0x08048450? It is not affected by ASLR. Is it still a memory address, or a relative point to the file?
If you look at the Intel Developer Manual instruction-set reference you can see that 0x0804846d <+32>: eb 15 jmp 0x8048484 encodes a relative address. i.e. it's the jmp rel8 short encoding. This works even in position-independent code, i.e. code which can run when mapped / loaded at any address.
ASLR means that the address of the stack (and optionally code+data) in the executable can change every time you load the file into memory. Obviously, once the program is loaded, the addresses won't change anymore, until it is loaded again. So if you know the address at runtime, you can target it, but you can't write an exploit assuming a fixed address.
GDB is showing you addresses of code in the virtual-memory space of your process, after any ASLR. (BTW, GDB disables ASLR by default: set disable-randomization on|off to toggle.)
For executables, it's common that only the stack pointer is ASLRed, while the code is position-dependent and loaded at a fixed address, so code and static data addresses are link-time constants, so code like push OFFSET .LC0 / call puts can work, hard-coding the address of the string constant into a push imm32.
Libraries usually need to be position-independent anyway, so ASLR can load them at a randomized address.
But ASLR for executables is possible and becoming more common, either by making position-independent executables (Linux), or by having the OS fix-up every hard-coded address when it loads the executable at a different address than it was compiled for (Windows).
Addresses only have a 1:1 relation to the position within the file only in a relative sense within the same segment. i.e. the next byte of code is the next byte of the file. The headers of the executable describe which regions of the file are what (and where they should be mapped by the OS's program loader).
The meaning of the addresses shown differs in three cases:
For executable files
For DLLs (Windows) or shared objects (.so, Linux and Un*x-like)
For object files
For executables:
Executable files typically cannot be loaded to any address in memory. In Windows there is the possibility to add a "relocation table" to an executable file (required for very old Windows versions); if this is not present (typically the case when using GCC) then it is not possible to load the file to another memory location. In Linux it is never possible to load the executable to another location.
You may try something like this:
static int a;
printf("%X\n", &a);
When you execute the program 100 times you see that the address of a is always the same so no ASLR is done for the executable file itself.
The addresses dumped by objdump are absolute addresses.
For DLLs / .so files:
The addresses are relative to the base address of the DLL (under Linux) or they are absolute addresses (under Windows) that will change when the DLL is loaded into another memory area.
For object files:
When dumping an object file the addresses are relative to the currently displayed section. If there are multiple ".text" sections in a file the addresses will start at 0 for each section.
I'm reading about TCustomVariantType and would like to know if there's a way to override the behaviour when a variable of the custom variant type gets called with one or more array indexes. If I do a quick debug with the debug DCU's on a[1] where a is a variant, I see _VarArrayGet gets called, but it funnels to a call to SafeArrayPtrOfIndex or SafeArrayGetElement, without a way to provide an alternative. I see older versions used to have a VariantManager, but this is deprecated. Is there a way to replace the _VarArrayGet pointer?
How is the system wired up so that a[x] ends up as a call to VarArrayGet(a,[x])?
The compiler in modern versions of Delphi has built in knowledge of variants and hard-wires the call to VarArrayGet. Look at the code the x86 compiler emits:
d := V[0];
is translated into:
004234D7 6A00 push $00
004234D9 6A01 push $01
004234DB 6858AF4200 push $0042af58
004234E0 8D45C8 lea eax,[ebp-$38]
004234E3 50 push eax
004234E4 E81BD8FFFF call #VarArrayGet
004234E9 83C410 add esp,$10
004234EC 8D45C8 lea eax,[ebp-$38]
004234EF E864B8FFFF call #VarToReal
004234F4 DD1D68AF4200 fstp qword ptr [$0042af68]
004234FA 9B wait
There is simply no extension point available to you.
Your best option if you wish to change the behaviour is to use a runtime code detour.
I intend to use Qemu to generate a memory trace for the execution of a x86 guest operating system.
According to tcg wiki page, Qemu uses a handful of helpers to generate load/stores to the target(guest) memory.
This list of instructions is tcg_gen_qemu_ld8s/u, tcg_gen_qemu_ld16s/u, tcg_gen_qemu_ld32s/u, tcg_gen_qemu_ld64. (We have a similar set for store instructions).
I am trapping all calls to the above functions in the target-i386/translate.c file
However, I am still missing load/stores of certain instructions like
cmp ecx, [r12+0x4]
mov r10b, [r13+0x0]
mov byte [rax+0xf0000], 0x0
mov byte [rax+rdx], 0x0
Questions :
Can someone please point to other load/store points (direct or indirect) that I am missing ??
Does qemu provide a single entry point function for accesses to guest memory (like guest_read()) which can be instrumented for tracing all loads from the guest memory ???
Can somebody please point to a good documentation where I can understand how qemu maintains the state of the guest memory ??
Sorry friends for the misleading instructions in the previous mail.
cmp ecx, [r12+0x4]
mov r10b, [r13+0x0]
mov byte [rax+0xf0000], 0x0
mov byte [rax+rdx], 0x0
It seems all the above instructions are getting covered with the tcg_gen_ld/st helpers.
But now I have stumbled upon another problem :
I initially thought that all the interactions with the guest memory happen through the helper instructions in the translate.c file.
However, I found that the helper functions for some instructions like cmpxcgh8b and cmpxchg16b are actually accessing guest memory.
So, does it mean there are more than one entry points for reading guest memory.
Can some one please explain how are the ldq and stq instructions translated to access the guest memory ??
The other functions that load data are called cpu_ld*_data and cpu_st*_data, or cpu_ld*_data_ra and cpu_st*_data_ra. The _ra version have an additional argument, which is the address of the caller in the generated code. It is used to compute the address of the faulting instruction in case the load or store generates a page fault.
For example, grepping for cmpxchg8b gives
target/i386/mem_helper.c:void helper_cmpxchg8b(CPUX86State *env, target_ulong a0)
and inside that function:
uintptr_t ra = GETPC();
...
oldv = cpu_ldq_data_ra(env, a0, ra);
newv = (cmpv == oldv ? newv : oldv);
/* always do the store */
cpu_stq_data_ra(env, a0, newv, ra);