Community
Participate
Working Groups
When debugging a process in a remote target, using an SDK that is not in-sync with the target, severe problems can occur. However, this situation is not easy visible for the user. For instance, the only sign that something is wrong is when GDB loads shared libraries, because it prints warnings like the following in its console: warning: .dynamic section for ".../usr/lib64/liblttng-ust.so.0" is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for ".../usr/lib64/liblttng-ust-tracepoint.so.0" is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for ".../usr/lib64/liburcu-bp.so.2" is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for ".../usr/lib64/liburcu-cds.so.2" is not at the expected address (wrong library or version mismatch?) This mismatch should be reported in a way that the user can be aware of the problem. Could it maybe be reported in the "Modules View"?
Is this warning reported in an MI notification? Or just in the CLI output? Attaching the gdb traces would be helpful.
GDB has the compare-sections command, which can be used to confirm that the executable sections on the host match those on the target. CDT could optionally use it after connecting to a remote target to make sure that what running is the same as what GDB thinks is running. However, AFAIK, it only checks the sections of the main executable, not the shared libraries. I think it would be possible to improve the command so that it also checks the libs. I filed a bug/enhancement request for GDB: https://sourceware.org/bugzilla/show_bug.cgi?id=20124 Note that there is no MI equivalent to compare-sections yet [1], which would be another good enhancement to have in GDB. [1] It seems like it existed a long while ago, but it's not there anymore: http://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_228.html
Created attachment 261895 [details] GDB Traces and Console output
GDB Traces attached. The warning is reported in the CLI output.
(In reply to Simon Marchi from comment #2) > GDB has the compare-sections command, which can be used to confirm that the > executable sections on the host match those on the target. CDT could > optionally use it after connecting to a remote target to make sure that what > running is the same as what GDB thinks is running. However, AFAIK, it only > checks the sections of the main executable, not the shared libraries. I > think it would be possible to improve the command so that it also checks the > libs. I filed a bug/enhancement request for GDB: > > https://sourceware.org/bugzilla/show_bug.cgi?id=20124 > > Note that there is no MI equivalent to compare-sections yet [1], which would > be another good enhancement to have in GDB. > > [1] It seems like it existed a long while ago, but it's not there anymore: > http://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_228.html Hmmm although when connecting to gdbserver, the libraries are typically not loaded yet, and there might be other loaded later anyway. So we would have to track =library-loaded events and issue compare sections for libraries there.
(In reply to Simon Marchi from comment #5) > (In reply to Simon Marchi from comment #2) > > GDB has the compare-sections command, which can be used to confirm that the > > executable sections on the host match those on the target. CDT could > > optionally use it after connecting to a remote target to make sure that what > > running is the same as what GDB thinks is running. However, AFAIK, it only > > checks the sections of the main executable, not the shared libraries. I > > think it would be possible to improve the command so that it also checks the > > libs. I filed a bug/enhancement request for GDB: > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=20124 > > > > Note that there is no MI equivalent to compare-sections yet [1], which would > > be another good enhancement to have in GDB. > > > > [1] It seems like it existed a long while ago, but it's not there anymore: > > http://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_228.html > > Hmmm although when connecting to gdbserver, the libraries are typically not > loaded yet, and there might be other loaded later anyway. So we would have > to track =library-loaded events and issue compare sections for libraries > there. Yes, we need to track the "library" events to handle this issue. As you said there are two cases: 1. library is loaded when the session is being launched 2. library is loaded after the session is started as a result of executing a run control command In both cases we need to pop up a dialog and ask the user whether he/she wants to continue. If the answer is "no" in case 1 we need to abort the launch and in case 2 we need to terminate the session. If the answer is "yes" we need to modify the library entry in the Modules view to reflect the symbols mismatch. What do you think?
(In reply to Mikhail Khodjaiants from comment #6) > (In reply to Simon Marchi from comment #5) > > (In reply to Simon Marchi from comment #2) > > > GDB has the compare-sections command, which can be used to confirm that the > > > executable sections on the host match those on the target. CDT could > > > optionally use it after connecting to a remote target to make sure that what > > > running is the same as what GDB thinks is running. However, AFAIK, it only > > > checks the sections of the main executable, not the shared libraries. I > > > think it would be possible to improve the command so that it also checks the > > > libs. I filed a bug/enhancement request for GDB: > > > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=20124 > > > > > > Note that there is no MI equivalent to compare-sections yet [1], which would > > > be another good enhancement to have in GDB. > > > > > > [1] It seems like it existed a long while ago, but it's not there anymore: > > > http://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_228.html > > > > Hmmm although when connecting to gdbserver, the libraries are typically not > > loaded yet, and there might be other loaded later anyway. So we would have > > to track =library-loaded events and issue compare sections for libraries > > there. > > Yes, we need to track the "library" events to handle this issue. As you said > there are two cases: > 1. library is loaded when the session is being launched > 2. library is loaded after the session is started as a result of executing a > run control command > In both cases we need to pop up a dialog and ask the user whether he/she > wants to continue. Just to be sure, you mean popup a dialog if we find the library doesn't match, not every time any library gets loaded? > If the answer is "no" in case 1 we need to abort the launch and in case 2 we > need to terminate the session. > If the answer is "yes" we need to modify the library entry in the Modules > view to reflect the symbols mismatch. > What do you think? There might be some implementation details that make it a bit awkward. When we receive the =library-loaded event, the target keeps running, so we can't do compare-sections unless we interrupt it. This applies both when using mi-async on and off. When it's on, compare-sections will most likely fail because we can't read memory of a running thread. When it's off, we can't even send commands to gdb.
Just in case you don't know: I think it's worth noting that there is a (not yet approved/committed) "Validate binary before use" (https://sourceware.org/ml/gdb-patches/2015-08/msg00590.html) feature in the GDB pipeline which uses the "--build-id" feature of the GNU linkers. According to my understanding, it avoid the need of comparing all sections, which may be more costly time wise. And it would probably solve the need to stop the inferior on loading shared libraries (although I'm not sure about that)
