Re: Should a DW_OP_implicit_value be taken from the left end?

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Wed, 21 Dec 2016 20:42:25 +0100, Andreas Arnez wrote:
> Since DW_OP_implicit_value can express arbitrary amounts of structured
> or unstructured data, the notion of a "least significant byte" is
> meaningless.

That depends on what the compiler-debugger negotiate together, as specified by
the DWARF standard which is ambiguous in this case IIUC.


> The patch above makes it impossible for a
> DW_OP_implicit_pointer operation to refer to any sub-value within a
> DW_OP_implicit_value on big-endian targets.

When looking at the patch I think the patch may be wrong, I think the
endianity should affect at least also the lines:

        case DWARF_VALUE_LITERAL:
...
            ldata = ctx.data + byte_offset;
            n -= byte_offset;


> E.g., consider this code snippet:
> 
>   const char foo[] = "Hello, world!";
>   char *a = &foo[0];
>   char *b = &foo[7];
> 
> IMHO the compiler should be able to describe `foo' with a single
> DW_OP_implicit_value operation and `a' and `b' as DW_OP_implicit_pointer
> operations pointing into that value.

I would need a compilable + compiled code + DWARF output + GDB output to say
more.


> Any objections?

I really do not mind reverting the patch if you think so, that is up to the
maintainers.

But when you ask me I miss here stating what the current GCC version does
produce.  Is GDB behavior fixed with current GCC by your proposed patch
revert?  If it breaks do you plan to change/fix also GCC?  Does the GDB
testsuite (particulerly the entryval testcases) have no regressions on s390*?

>From my mail you reference I understand it as that my patch did fix some
entryval testcases with GCC that time.  Unfortunately the entryval testcases
are provided as .S files prebuilt by GCC that time and they are difficult to
reproduce with newer GCC as -O2 -g code changes too much with different GCC
version, breaking various compiled code assumptions of the .exp file.

My feeling is that my patch did fix some entryval testcases on bigendian but
I also guess my patch was wrong - it only accidentally fixed them, the right
fix for big endian should look differently.


Jan