[Bug compile/25575] Compile command crashes or fails with AVX registers and -O2

[Bug compile/25575] Compile command crashes or fails with AVX registers and -O2

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25575

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
The problem here seems to me that the DWARF expression for 'x' references
register 207, but up in generate_c_for_variable_locations:

  gdb::unique_xmalloc_ptr<unsigned char> registers_used
    (XCNEWVEC (unsigned char, gdbarch_num_regs (gdbarch)));

and

(top-gdb) p gdbarch_num_regs(gdbarch)
$6 = 155

So this is also an invalid memory access as well I think.


Digging a bit deeper I see that ymm0 is apparently a pseudo-register.
So, I think there are a couple of problems here.

One is that the DWARF-lowering code should probably translate
to gdb register numbers.

But, to do this, we'd also have to handle pseudos.  But, I don't think
there's a way to translate pseudo-registers to their underlying GDB
registers.  I guess this can be done in an ad hoc way by the tdep code.

Not sure how to approach this.  Maybe the whole thing could be
rephrased in terms of regsets?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug compile/25575] Compile command crashes or fails with AVX registers and -O2

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25575

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
> One is that the DWARF-lowering code should probably translate
> to gdb register numbers.

I was confused here -- it does do this, but the problem is still that
the translation winds up with a cooked register, not a raw register.
The problem with just making the vector bigger is that since
a cooked register is based on some underlying real register, then
when restoring register values we wouldn't know what to do.

Agent expressions handle this via a gdbarch method.
Maybe 'compile' must do the same.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug compile/25575] Compile command crashes or fails with AVX registers and -O2

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25575

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b10bae18753862874628f902796eb1cd3925f95d

commit b10bae18753862874628f902796eb1cd3925f95d
Author: Tom Tromey <tom@tromey.com>
Date:   Sat Jan 23 12:20:11 2021 -0700

    Avoid crash when "compile" expression uses cooked register

    If the "compile" command is used with an expression that happens to
    require a cooked register, then GDB can crash.  This patch does not
    fix the bug, but at least turns the crash into an error instead.

    2021-01-23  Tom Tromey  <tom@tromey.com>

            PR compile/25575
            * compile/compile-loc2c.c (note_register): New function.
            (pushf_register_address, pushf_register): Use it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.