support

Forum Replies Created

Viewing 15 posts - 7,111 through 7,125 (of 7,850 total)
  • Author
    Posts
  • in reply to: -var-create: unable to create variable object #3069
    support
    Keymaster

    Hi,

    The root cause for this message is incompatibility between the debug information issued by GCC and read by GDB. If you encounter it again, try experimenting with the -gdwarf- GCC flag.

    in reply to: Use Gcc 4.7 #3365
    support
    Keymaster

    Hi,

    Is gcc 4.7 officially included in the latest stable Raspbian distro? If not, it may end up being incompatible with the image.

    in reply to: Minor feature request #3073
    support
    Keymaster

    Hi,

    If we make it a background operation and you try to build/edit something while the update is in progress, this may cause unpredictable results. We actually use a cloud-based CDN to cache the BSP/EDP updates, so normally they should be downloaded fairly fast. Does it take more time than a minute or so on your machine? Is it about the toolchain update, BSP update or either of them?

    in reply to: Build time reports 00:09.991 every time I build? #3074
    support
    Keymaster

    Hi,

    The message actually comes from Visual Studio, not VisualGDB. Please try installing the latest service pack.

    in reply to: Delay before every build #3079
    support
    Keymaster

    Hi,

    Does it also happen when you launch VisualGDB build from command line? Does your project have lots of source files? Is Visual Studio window responsive during the delay?

    in reply to: VisualGDB hangs under Teamcity #3081
    support
    Keymaster

    Hi,

    Actually you don’t need VisualGDB to do the remote build. Simply run the make.exe provided with your toolchain in the project directory and ensure that the toolchain binary directory is on the PATH.
    Would that work for you?

    in reply to: STemWin compiled Library #3097
    support
    Keymaster

    Hi,

    You can add the full path to the file to the “Additional linker inputs” field. Let us know if that works for you.

    in reply to: A collection of problems I ran into using VisualGDB #3375
    support
    Keymaster

    Hi,

    1. Unfortunately, the Android tools provided by Google are not very stable, so you often need to try several combinations to find one that works.
    Note that if your breakpoints don’t work, this can be caused by 3 independent problems:
    a. Gdbserver fails to get the shared library list from the OS. This can be detected by checking the output of ‘info shared’ for strange things. It can be fixed by trying various gdbserver versions.
    b. Particular versions of gdb and gdbserver are incompatible. This would cause either of them to crash. A workaround would be to try different versions of gdb/gdbserver.
    c. The debug symbols produced by gcc are not correctly recognized by gdb. This would cause the modules to appear properly, but the breakpoints won’t set or the variables will be missing. It can be fixed by changing the debug information format of gcc (-gdwarf-xxx flags) or using a different gcc version.

    2. VisualGDB expects a certain file layout coming from NDK build scripts and the easiest way to support a custom build system is to emulate it just like you are doing it.
    3. This is actually handled by gdb itself, not VisualGDB. When the target loads a library called xxx.so the GDB searches the directories set via set solib-search-path for a library with a matching name and gets symbols from there. The easiest workaround for mismatching names would be to simply make a copy of the file on the Windows side with a matching name. You can also put it into a different directory and specify it via set solib-search-path.
    4. We also don’t have any special flag for starting gdbserver as root. We could add a flag for that, but if the current workaround works, we would suggest using it as it’s a fairly rare scenario.
    5. The normal Attach dialog does not support attaching to Android processes. We will consider adding support for this in one of the next releases.

    in reply to: include <mysql/mysql.h> error"undefined reference to" #3364
    support
    Keymaster

    Hi,

    You need to add the MySQL library to the ‘libraries’ setting in the VisualGDB Project Properties. Specify the name without the ‘lib’ prefix and ‘.a’ suffix. E.g. if the library name is libmysql.a, simply specify ‘mysql’ in the ‘libraries’ field.
    You may also need to put extern “C” around the include file if it does not contain it.

    in reply to: Feature request: The Go lang #3374
    support
    Keymaster

    The Go language currently looks more like a research project than a mature industrial tool, hence we would probably not find enough users to justify any heavy modifications to VisualGDB to support it.
    However if GDB can already debug it, you should be able to use the Quick Debug feature or create a custom project to use VisualGDB as a high-level wrapper around GDB.

    in reply to: Fail to download kernel symbols #3062
    support
    Keymaster

    Yes, VisualKernel is focusing on seamless debugging experience, so configuring debugging is a mandatory step. If you just need to build your module, you can simply use the command line.

    in reply to: Fail to download kernel symbols #3065
    support
    Keymaster

    Hi,

    The Raspberry Pi distro does not include kernel debug packages, so if you want to develop/debug kernel modules for it, you need to build the kernel from source code. Follow this tutorial for more details: http://sysprogs.com/VisualKernel/tutorials/raspberry/basicmodule/

    in reply to: Problem updating VisualGDB to the latest version #3098
    support
    Keymaster

    Hi,

    This looks like a corrupt MSI file. Please try downloading it again.

    in reply to: BUG when gdb remote debug connecting #3371
    support
    Keymaster

    Hi,

    Thanks, this looks like a bug. We’ll add a fix for it to the next maintenance release. As a workaround you can select the manual GDB mode and specify the target selection command manually.

    in reply to: Semihosting broken with latest GCC arm-eabi update #3334
    support
    Keymaster

    Hi,

    This can be related to the implementation of initialize_monitor_handles() in newlib 2.1.0:

    void
    initialise_monitor_handles (void)
    {
    int i;
    
    #ifdef ARM_RDI_MONITOR
    int volatile block[3];
    
    block[0] = (int) ":tt";
    block[2] = 3;     /* length of filename */
    block[1] = 0;     /* mode "r" */
    monitor_stdin = do_AngelSWI (AngelSWI_Reason_Open, (void *) block);
    
    block[0] = (int) ":tt";
    block[2] = 3;     /* length of filename */
    block[1] = 4;     /* mode "w" */
    monitor_stdout = monitor_stderr = do_AngelSWI (AngelSWI_Reason_Open, (void *) block);
    #else
    int fh;
    const char * name;
    
    name = ":tt";
    asm ("mov r0,%2; mov r1, #0; swi %a1; mov %0, r0"
    : "=r"(fh)
    : "i" (SWI_Open),"r"(name)
    : "r0","r1");
    monitor_stdin = fh;
    
    name = ":tt";
    asm ("mov r0,%2; mov r1, #4; swi %a1; mov %0, r0"
    : "=r"(fh)
    : "i" (SWI_Open),"r"(name)
    : "r0","r1");
    monitor_stdout = monitor_stderr = fh;
    #endif
    
    for (i = 0; i < MAX_OPEN_FILES; i ++)
    openfiles.handle = -1;

    openfiles[0].handle = monitor_stdin;
    openfiles[0].pos = 0;
    openfiles[1].handle = monitor_stdout;
    openfiles[1].pos = 0;
    }

    Our toolchain includes a patch that declares this function as __attribute__((weak)), so you can simply get the newlib source code and add this one file to your project, setting ARM_RDI_MONITOR if you need it and modifying anything else you need. You won’t need to rebuild the libc or anything else, the functions from your manually added file will simply replace the default ones.

Viewing 15 posts - 7,111 through 7,125 (of 7,850 total)