0

Since upgrading to Ubuntu 19.10, gdb (8.3) is nearly unusable using programs compiled using the default gcc (9.2.1) using -O0 -ggdb -g3 because most displayed values for variables are wrong.

The project used to use -gdwarf-2 -g3. According to the gcc docs -ggdb provides the best support, but it doesn't make a difference.

Note that on a Fedora 30 machine running gdb Fedora 8.3-7.fc30 and gcc 9.2.1, everything is working fine. Both machines are x86_64.

Am I really the only one? Just to show what happens:

Thread 1 "swipl" hit Breakpoint 1, PL_error (
    pred=0x214 <error: Cannot access memory at address 0x214>, arity=32767, 
    msg=0x7ffff7df9468 <PL_unify_int64__LD+52> "\311\303\363\017\036\372UH\211\345H\203\354`H\211}\250H\211u\240dH\213\004%(", id=4160516576)
    at ../src/pl-error.c:94
94  { GET_LD
(gdb) bt
#0  PL_error (pred=0x214 <error: Cannot access memory at address 0x214>, 
    arity=32767, 
    msg=0x7ffff7df9468 <PL_unify_int64__LD+52> "\311\303\363\017\036\372UH\211\345H\203\354`H\211}\250H\211u\240dH\213\004%(", id=4160516576)
    at ../src/pl-error.c:94

If we look a the call site, we see

    return PL_error(NULL, 0, NULL, ERR_PERMISSION_PROC,
            ATOM_redefine, ATOM_imported_procedure, proc);

The first three arguments are all 0, but gdb gives claims they have some bogus value.

3
  • Compiled gdb from source using medium.com/@simonconnah/…. This gives the same result with exactly the same bogus variable values. Feb 3, 2020 at 16:40
  • Switching back to gcc-7 fixes the issues. This seems to be a gcc rather than a gdb issue. Remains why gcc-9 + gdb-8.3 do work fine on Fedora? Feb 3, 2020 at 19:56
  • Just updated to Ubuntu 20.04, providing gcc 9.3. The problem persists. Considering that Fedora gets this right, this seems an Ubuntu issue. Where should I report this to get attention? May 14, 2020 at 11:58

0

You must log in to answer this question.

Browse other questions tagged .