Re: [PATCH 2/7 v3] Tracepoint for ppc64.

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Wei-cheng Wang wrote:
> On Thu, Apr 9, 2015 at 12:57 AM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> > Wei-cheng Wang wrote:
> >> The fail cases in gdb-unavailable are caused by inaccessible vtable for object
> >> For x86, such structures (_ZVTxxx) are put in .rodata section, so gdb can read
> >> them in local file if not collected by tracepoint action, but for PowerpPC,
> >> they are put in .rel.ro sections.  Technically they not read-only, so gdb won't
> >> read them in file if not collected.
> >
> > Is this really a difference between Intel and PowerPC, or this is rather
> > a difference between different binutils levels?  I don't see off-hand
> > why this should be Power-specific ...  Do you have example assembler
> > code that shows the difference?

Ah, I think I see.  The difference is that on PowerPC, *all* code (even in
the main executable) is built as position-independent.  For PIC code, the
vtable must be relocated and hence reside in a .data.rel.ro section; while
for non-PIC code the vtable can be in .rodata.

So the same problem would probably appear on Intel as well if we build the
testcase as PIC or PIE.

> In this case, gdb wants to access (vtable for Derived + 32).
> Because it's not collected, gdb tries to see if the address is read-only,
> so it can access it from files.  See also remote_xfer_live_readonly_partial.

Hmm.  I guess we could try to add support for using .data.rel.ro sections
from the executable file as well; the contents would have to be relocated
by GDB, but there's already support to do that in other cases ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com