same as title.
It's so simple binary.
gets and print
lldb in local iDevice is fine.
debbugging in local iDevice directly
but in remote-ios platform, I dont' know how to pass stdin to binary.
debugging in remote lldb
iDevice : debugserver 127.0.0.1:1234 /qwerty
Mac.
lldb
platform select remote-ios
process connect connect://127.0.0.1:1234
Thanks to all the answers.
Related
I'd like to define a command which does X under gdb-multiarch, but prints out a helpful message when run under normal gdb. How can my script determine which of the two its run under?
Why? When I start gdb-multiarch, I can bind to a qemu-arm session. When I try that in gdb, I get bizarre errors. It's easy to forget and run gdb (and not -multiarch), and I want to my bind-to-qemu tell me "This must be run under gdb-multiarch".
Your question presumes that there is some difference between gdb and gdb-multiarch, but there doesn't have be any such difference.
Presumably on the OS you are using the gdb and gdb-multiarch are configured differently, with gdb only supporting native architecture, while gdb-multiarch supports cross-architecture debugging.
Presumably what you actually want to detect is that the target-architecture you need (arm ?) is / isn't supported by the current binary.
In the bind-to-qemu user-defined function, you can try to set architecture arm.
If that errors out, the rest of bind-to-qemu should not execute.
(Using STM32F767 microcontroller)
I have a remote debugging environment setup on a RPI using OpenOCD. I can connect to it just fine using GDB.
However since I am writing a bootloader I need to flash the firmware to a specific offset in flash memory. E.g bootloader starts at 0x800000 and firmware should start at 0x8010000 for example so the offset would be (0x10000).
This works fine locally using: mon flash write_bank 0 main.bin 0x10000
But since I don't have the main.bin in the RPI, is there a way I could use OpenOCD or GDB to specify my local file instead and that would be sent over the remote connection?
Note that I would not like to setup a FTP and thus am looking for an alternate solution.
Best regards
gdb should supports sending files to remote via the 'remote put '. But, when I try this in gdb, I get the response "Remote I/O error: Function not implemented". Seems like OpenOCD does not support this
Use "file" to select the file and then "load" will send the file across to the device.
I have:
A proprietary prototype ARM board (Cortex-M3 based) with eCos OS
The board has the programmed RedBoot bootloader
Serial line (RS-232)
GDB debugger for ARM (arm-eabi-gdb)
Host OS is Windows/Cygwin and/or Linux (actually, doesn't matter)
Problem: GDB debugger cannot connect to the target over the serial line.
What I want: is to sniff the packets of the GDB remote protocol in order to undestand whether the GDB stub on the target is alive and operating.
Details: RedBoot has an option to pass the target's control to the built-in GDB stub. I know that the RedBoot is alive, I can connect to it and send it commands over the serial line. The RedBoot manual says that the switch to the GDB stub can be made by typing $ or + symbols (which are actually the prefixes of the GDB remote protocol packets). It seems to work for when I send those symbols the terminal dies. But I'm not sure if the RedBoot was compiled with the GDB stub support (don't ask me why :-)).
Then, when I try to connect to the board with my GDB debugger I get the following picture (on Windows):
(gdb) target remote COM3
Remote debugging using COM3
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
The port is correct, the baudrate as well. Actually the same output I get if I try to do the same with another serial port which is not connected with anything.
What I want to know is does GDB stub send back anything or not?
Intuitively I thought that probably
set verbose on
would help, but GDB manual says it has very a limited effect and my case is beyond it.
May be it is possible to compile GDB debugger with a macro which enables debug logging?
What I want to know is does GDB stub send back anything or not?
Do this (before target remote):
(gdb) set debug remote 1
I'm debugging with the Codesourcery version of gdb for ARM (i.e. arm-none-eabi-gdb) and attempting to generate a corefile for later inspection. OpenOCD is my GDB target. All gdb tells me when I run 'gcore' or 'generate-core-file' is "Can't create corefile". Any suggestions? In general is it possible to do a core dump with a remote target?
It doesn't seem possible yet, but there is some promising discussion on the GDB mailing list
here and here. As an alternative maybe you could try the following?
dump memory filename.bin start_addr end_addr
restore filename.bin binary start_addr
where you fill in start_addr and end_addr appropriately. You'd have to save registers by hand.
I develop a c++ CGI program that runs under Windows and Linux.
This program calls another program like this:
system("otherProgram.exe arguments");
I also tried:
spawnl(_P_WAIT, "otherProgram.exe", "argument1", NULL);
This works fine in my debugger and in my Virtual Machine, but on my test server it doesn't work.
The system call returns -1.
Any ideas why?
This is likely a permissions issue. By default your CGI application will be run as if by user nobody. The program you want to launch should be executable by "nobody".
Is the directory containing "otherProgram.exe" in one of the directories in your PATH environment variable in the test box? That is, does your operating system know how to find that program?