| Using GDB debugger for debugging CC files [message #1831761] |
Fri, 28 August 2020 05:48  |
Eclipse User |
|
|
|
Hi,
As we know that it is not possible to add breakpoints and debug the compiled C++ files using Titan command line debugger. So is it possible to use GDB debugger for debugging the executable generated. I have tried and tried to add breakpoints to the executable on HC but i am not catching up the right steps to do this while having MTC and HC active (connected). Can you guys guide me?
Best Regards,
Mujeeb
|
|
|
|
|
|
|
|
| Re: Using GDB debugger for debugging CC files [message #1831870 is a reply to message #1831766] |
Tue, 01 September 2020 08:37  |
| Eclipse User |
|
|
|
Gábor Szalai wrote on Fri, 28 August 2020 12:02The HC spawns a separate process for MTC and any other PTC. So any test code is running on MTC or PTC process not inside the HC process.
You should attach the gdb to the right process not the HC process.
But I recommend to add some log statement to the test port code.
I need some guidance on this
Well i tried to attach the process and this worked but i am facing an issue when i attach the process i am not able to give gdb related commands in the terminal as test executions starts, the same happens on the client side where the executable is run,
Server Side:
Quote:
[mreh@abc bin]$ gdb ./mctr_cli cfg.cfg
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-92.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/mreh/Desktop/TTCN/ttcn3-6.5.pl0-linux64-gcc4.4.5-rhel6/bin/mctr_cli...(no debugging symbols found)...done.
"/home/mreh/Desktop/TTCN/ttcn3-6.5.pl0-linux64-gcc4.4.5-rhel6/bin/cfg.cfg" is not a core dump: File format not recognized
(gdb) run cfg.cfg
Starting program: /home/mreh/Desktop/TTCN/ttcn3-6.5.pl0-linux64-gcc4.4.5-rhel6/bin/mctr_cli cfg.cfg
[Thread debugging using libthread_db enabled]
*************************************************************************
* TTCN-3 Test Executor - Main Controller 2 *
* Version: CRL 113 200/6 R5A *
* Copyright (c) 2000-2018 Ericsson Telecom AB *
* All rights reserved. This program and the accompanying materials *
* are made available under the terms of the Eclipse Public License v2.0 *
* which accompanies this distribution, and is available at *
* https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.html *
*************************************************************************
Using configuration file: cfg.cfg
MC@abc Unix server socket created successfully.
[New Thread 0x7ffff7fdc700 (LWP 2902)]
MC@abc: Listening on TCP port 9034.
MC2> MC@abc: New HC connected from 127.0.0.1 [127.0.0.1]. abc: Linux 2.6.32-754.14.2.el6.x86_64 on x86_64.
cmtc
MC@abc: Downloading configuration file to all HCs.
MC@abc: Configuration file was processed on all HCs.
MC@abc: Creating MTC on host 127.0.0.1.
MC@abc: MTC is created.
MC2> smtc
Executing all items of [EXECUTE] section.
MC2> MTC@abc: Test case TC_22_2_1 started.
3@abc: Warning: Unknown XER encoding requested; using Basic XER.
Program received signal SIGINT, Interrupt.
0x0000003cf560e82d in read () from /lib64/libpthread.so.0
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.212.el6_10.3.x86_64 libgcc-4.4.7-23.el6.x86_64 libstdc++-4.4.7-23.el6.x86_64 ncurses-libs-5.7-4.20090207.el6.x86_64 openssl-1.0.1e-58.el6_10.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) quit
A debugging session is active.
Inferior 1 [process 2899] will be killed.
Client Side:
Quote:[mreh@abc NBIOT]$ gdb ./TTCN3_testcases.exe
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-92.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/mreh/Desktop/TTCN/ttcn3-6.5.pl0-linux64-gcc4.4.5-rhel6/NBIOT/TTCN3_testcases.exe...(no debugging symbols found)...done.
(gdb) run -s IPADDRESSES 9034
Starting program: /home/mreh/Desktop/TTCN/ttcn3-6.5.pl0-linux64-gcc4.4.5-rhel6/NBIOT/TTCN3_testcases.exe -sIPADDRESSES 9034
[Thread debugging using libthread_db enabled]
TTCN-3 Host Controller (parallel mode), version CRL 113 200/6 R5A
Detaching after fork from child process 3298.
Detaching after fork from child process 3307.
So kindly is there some solution to this? how i give gdb commands during test execution? and can bring back the gdb terminal?
Thanks again every one for your kind advices and help :)
Best Regards,
Mujeeb
[Updated on: Thu, 03 September 2020 10:36] by Moderator |
|
|
| Re: Using GDB debugger for debugging CC files [message #1831974 is a reply to message #1831870] |
Fri, 04 September 2020 02:54 |
| Eclipse User |
|
|
|
For debugging external function I suggest to use single mode. In single mode there are no separate mctr, host controller and MTC/PTC processes. Just one mtc, on which the code is executed. Much easier to use gdb.
Also I advise to use debug printouts instead of gdb.
Just add a similar function to your code:
void my_debug(const char *fmt, ...) { /
TTCN_Logger::begin_event(TTCN_DEBUG);
TTCN_Logger::log_event("My debug: ");
va_list args;
va_start(args, fmt);
TTCN_Logger::log_event_va_list(fmt, args);
va_end(args);
TTCN_Logger::end_event();
}
And call this function like the printf. And add the DEBUG flag to the FileMask like:
FileMask:= LOG_ALL | DEBUG
How to find the pid of the MTC or ptc:
When the MTC or PTC is created the pid is logged into the hc log file. Start the test case, check the hc log for the pid, and attach the gdb to that process.
Probably you need to add some delays to the test code to have enough time to attach the gdb.
|
|
|
Powered by
FUDForum. Page generated in 1.27896 seconds
Home