This is most likely a gdb bug, we IIRC we agreed to collect all issues here.
With the not-yet-commited ppc64 arch support from Jeff, on 11SP4 ppc64 kernel dump (thus big endian), with crash-python running on x86_64, I see the following problem:

print(gdb.Value(0xc0000007ef86f5f0).cast(gdb.lookup_type('struct list_head').pointer()))
0xc0000007ef86f5f0

OK so far

print(gdb.Value(0xc0000007ef86f5f0).cast(gdb.lookup_type('char').pointer()))
0xc0000007ef86f5f0 "\300"

also OK, but:

print(gdb.Value(0xc0000007ef86f5f0).cast(gdb.lookup_type('struct list_head').pointer()).cast(gdb.lookup_type('char').pointer()))
0xf0f586ef070000c0 <error: Cannot access memory at address 0xf0f586ef070000c0>

I.e. casting from one kind of pointer to char pointer switches endianity.

Opposite direction as well:

print(gdb.Value(0xc0000007ef86f5f0).cast(gdb.lookup_type('char').pointer()).cast(gdb.lookup_type('struct list_head').pointer()))
0xf0f586ef070000c0

Interestingly enough, when "char *" is not involved at all...

print(gdb.Value(0xc0000007ef86f5f0).cast(gdb.lookup_type('struct page').pointer()).cast(gdb.lookup_type('struct list_head').pointer()))
0xc0000007ef86f5f0

This breaks the current implementation of container_of(), I have modified it locally to cast to long instead of charp.