date:20170117

Re: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374

2017-01-17 Thread Mark Millard

Using the new changed line (Plt use now):

uint64_t TocVA = Out::Plt->getVA();

changed the behavior and it gets farther for
-fuse-ld=lld based linking. But it is r2 leading
to r3 content that is dereferenced and 8(r3) fails
this time. This was in the process of finding
the new r2 value for the following bctrl.
r2==0x10018560 initially in __do_global_ctors_aux
seems wrong. If so then objlist_call_init produced
a wrong r2 value.

[I've no clue if this is what you expected from
the Plt experiment or not.]

Details. . .

# /usr/local/bin/gdb a.out
GNU gdb (GDB) 7.11.1 [GDB v7.11.1 for FreeBSD]
. . .
Reading symbols from a.out...done.
(gdb) run
Starting program: /root/c_tests/a.out 

Program received signal SIGSEGV, Segmentation fault.
0x100104a8 in .__do_global_ctors_aux ()
(gdb) bt
#0  0x100104a8 in .__do_global_ctors_aux ()
#1  0x10010518 in ._init ()
#2  0x5002ac78 in objlist_call_init (list=, 
lockstate=) at /usr/src/libexec/rtld-elf/rtld.c:2541
#3  0x50029fa8 in _rtld (sp=, exit_proc=, 
objp=) at /usr/src/libexec/rtld-elf/rtld.c:668
#4  0x500279b0 in ._rtld_start () at 
/usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:83
Backtrace stopped: frame did not save the PC
(gdb) disass
Dump of assembler code for function .__do_global_ctors_aux:
   0x10010470 <+0>: mflrr0
   0x10010474 <+4>: std r31,-8(r1)
   0x10010478 <+8>: std r0,16(r1)
   0x1001047c <+12>:stdur1,-128(r1)
   0x10010480 <+16>:addis   r3,r2,-1 < Note: r3 derives 
from r2
   0x10010484 <+20>:mr  r31,r1
   0x10010488 <+24>:addir3,r3,32464
   0x1001048c <+28>:std r30,112(r31)
   0x10010490 <+32>:ld  r3,-8(r3)
   0x10010494 <+36>:cmpdi   r3,-1
   0x10010498 <+40>:beq 0x100104d4 <.__do_global_ctors_aux+100>
   0x1001049c <+44>:addis   r4,r2,-1
   0x100104a0 <+48>:addir4,r4,32464
   0x100104a4 <+52>:addir30,r4,-8
=> 0x100104a8 <+56>:ld  r4,8(r3) < Note: 8(r3) 
fails.
   0x100104ac <+60>:ld  r11,16(r3)
   0x100104b0 <+64>:ld  r3,0(r3)
   0x100104b4 <+68>:std r2,40(r1)
   0x100104b8 <+72>:mr  r2,r4< Note: 8(r3) 
result should have been the new r2 value
   0x100104bc <+76>:mtctr   r3
   0x100104c0 <+80>:bctrl
   0x100104c4 <+84>:ld  r2,40(r1)
   0x100104c8 <+88>:ldu r3,-8(r30)
   0x100104cc <+92>:cmpdi   r3,-1
   0x100104d0 <+96>:bne 0x100104a8 <.__do_global_ctors_aux+56>
   0x100104d4 <+100>:   ld  r30,112(r31)
   0x100104d8 <+104>:   addir1,r1,128
   0x100104dc <+108>:   ld  r0,16(r1)
   0x100104e0 <+112>:   ld  r31,-8(r1)
   0x100104e4 <+116>:   mtlrr0
   0x100104e8 <+120>:   blr
   0x100104ec <+124>:   .long 0x0
   0x100104f0 <+128>:   .long 0x0
   0x100104f4 <+132>:   .long 0x0
End of assembler dump.
(gdb) info registers
r0 0x10010518   268502296
r1 0xcbf0   18446744073709538288
r2 0x10018560   268535136
r3 0x7ca903a64e800421   8982714944583631905
r4 0x10010430   268502064
r5 0x100300d0   268632272
r6 0x50043ab0   1342454448
r7 0x50067f00   1342603008
r8 0xdfcc   18446744073709543372
r9 0x0  0
r100x0  0
r110x0  0
r120xdfd0   18446744073709543376
r130x50057010   1342533648
r140x0  0
r150x0  0
r160x50047f00   1342471936
r170x500613e0   1342575584
r180x50253388   1344615304
r190x2  2
r200x0  0
r210x9  9
r220x0  0
r230x40 18014398509481984
r240x5004a100   1342480640
r250x5004c400   1342489600
r260xcd18   18446744073709538584
r270xcd3c   18446744073709538620
r280xcd3c   18446744073709538620
r290x0  0
r300x10010428   268502056
r310xcbf0   18446744073709538288
pc 0x100104a8   0x100104a8 <.__do_global_ctors_aux+56>
msr
cr 0x48200c00   1210059776
lr 0x10010518   0x10010518 <._init+24>
ctr0x10010500   268502272
xer0x2000   536870912
(gdb) info file
Symbols from "/root/c_tests/a.out".
Native process:
Using the running image of child LWP 100093 of process 1091.
While running this, GDB does not access memory

Re: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374

2017-01-17 Thread Roman Divacky

Go with Out.

On Tue, Jan 17, 2017 at 01:53:14PM -0800, Mark Millard wrote:
> On 2017-Jan-17, at 11:54 AM, Roman Divacky  wrote:
> 
> . . .
> > I wonder if it doesnt work because of my first patch (the one to turn GOT
> > reloc into PLT one).
> > 
> > LLD understands that we use GOT as TOC (which was true before my patch),
> > I wonder if something like this:
> > 
> > ndex: tools/lld/ELF/Target.cpp
> > ===
> > --- tools/lld/ELF/Target.cpp(revision 292071)
> > +++ tools/lld/ELF/Target.cpp(working copy)
> > @@ -1070,7 +1070,8 @@
> > }
> > 
> > PPC64TargetInfo::PPC64TargetInfo() {
> > -  PltRel = GotRel = R_PPC64_GLOB_DAT;
> > +  GotRel = R_PPC64_GLOB_DAT;
> > +  PltRel = R_PPC64_JMP_SLOT;
> >   RelativeRel = R_PPC64_RELATIVE;
> >   GotEntrySize = 8;
> >   GotPltEntrySize = 8;
> > @@ -1099,7 +1100,7 @@
> >   // TOC starts where the first of these sections starts. We always create a
> >   // .got when we see a relocation that uses it, so for us the start is 
> > always
> >   // the .got.
> > -  uint64_t TocVA = In::Got->getVA();
> > +  uint64_t TocVA = In::Plt->getVA();
> > 
> >   // Per the ppc64-elf-linux ABI, The TOC base is TOC value plus 0x8000
> >   // thus permitting a full 64 Kbytes segment. Note that the glibc startup
> 
> The modern 3.9.1 source does not match for the last. Note the
> "Out" vs. "In" below ("svnlite status" does not show my source
> as different in this area):
> 
> uint64_t getPPC64TocBase() {
>   // The TOC consists of sections .got, .toc, .tocbss, .plt in that order. The
>   // TOC starts where the first of these sections starts. We always create a
>   // .got when we see a relocation that uses it, so for us the start is always
>   // the .got.
>   uint64_t TocVA = Out::Got->getVA();
>   
>   // Per the ppc64-elf-linux ABI, The TOC base is TOC value plus 0x8000
>   // thus permitting a full 64 Kbytes segment. Note that the glibc startup
>   // code (crt1.o) assumes that you can get from the TOC base to the
>   // start of the .toc section with only a single (signed) 16-bit relocation.
>   return TocVA + PPC64TocOffset;
> }
> 
> [Also the "// TOC . . ." comment is at line 1005 (given the prior
> GotRel vs. PltRel split into separate lines).]
> 
> Which should I use?: In vs. Out
> 
> > would make any difference? It's not correct but might shed some light on 
> > what needs to be done
> > if I am right.
> 
> Separately if I understand the change you are picking out which section
> is first of .got, .toc, .tocbss, .plt (.got.plt as well?). But for the
> order of things that would still make the .ctors, .dtors, .jcr, .dynamic,
> and .data sections as being inside the TOC and taking TOC address range
> space:
> 
>   0x10010560 - 0x100105c0 is .plt  <= 
> NOTE
>   0x1002 - 0x10020010 is .ctors
>   0x10020010 - 0x10020020 is .dtors
>   0x10020020 - 0x10020028 is .jcr
>   0x10020028 - 0x10020138 is .dynamic
>   0x10020138 - 0x10020138 is .got  <= 
> NOTE
>   0x1003 - 0x10030019 is .data
>   0x10030020 - 0x10030050 is .got.plt  <= 
> NOTE
>   0x10030050 - 0x100300a0 is .toc  <= 
> NOTE
> 
> Is that expected/desired/allowed?
> 
> > Could you explore this please?
> 
> After you report for sure for In vs. Out I'll take a stab
> at it.
> 
> ===
> Mark Millard
> markmi at dsl-only.net
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . .

2017-01-17 Thread Justin Hibbits

I was incorrect. The Freescale reference actually lists both numbers in the
instruction list (167/231 in A.1 and A.5, 334/462 in A.2).  The values you
listed are correct, and match what GCC generates as well.

- Justin

On Jan 17, 2017 13:49, "Roman Divacky"  wrote:

> Are you sure? My coy of PowerISA lists the numbers that I used? What makes
> you
> think it should be shifted by one bit?
>
> On Mon, Jan 16, 2017 at 08:45:58PM -0600, Justin Hibbits wrote:
> > The patch is incorrect, the 'xo' values are off by one bit (inline
> > change):
> >
> >
> > On Dec 5, 2016, at 10:19 AM, Roman Divacky wrote:
> >
> > > Can you try this patch?
> > >
> > > Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
> > > ===
> > > --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
> > > +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
> > > @@ -2373,6 +2373,12 @@
> > > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR),
> > >  "mftb $RT, $SPR", IIC_SprMFTB>;
> > >
> > > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
> >
> > 334 should be 167
> >
> > > + "mfpmr $RT, $PMRN", IIC_IntGeneral>;
> > > +
> > > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
> > > + "mtpmr $PMRN, $RS", IIC_IntGeneral>;
> >
> > 462 should be 231.
> >
> > > +
> > > // A pseudo-instruction used to implement the read of the 64-bit
> > > cycle counter
> > > // on a 32-bit target.
> > > let hasSideEffects = 1, usesCustomInserter = 1 in
> > >
> >
> > I'll have a patch ready for LLVM review within a week or so, including
> > some level of scheduling.
> >
> > - Justin
>
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374

2017-01-17 Thread Roman Divacky

Mark,

I wonder if it doesnt work because of my first patch (the one to turn GOT
reloc into PLT one).

LLD understands that we use GOT as TOC (which was true before my patch),
I wonder if something like this:

ndex: tools/lld/ELF/Target.cpp
===
--- tools/lld/ELF/Target.cpp(revision 292071)
+++ tools/lld/ELF/Target.cpp(working copy)
@@ -1070,7 +1070,8 @@
 }
 
 PPC64TargetInfo::PPC64TargetInfo() {
-  PltRel = GotRel = R_PPC64_GLOB_DAT;
+  GotRel = R_PPC64_GLOB_DAT;
+  PltRel = R_PPC64_JMP_SLOT;
   RelativeRel = R_PPC64_RELATIVE;
   GotEntrySize = 8;
   GotPltEntrySize = 8;
@@ -1099,7 +1100,7 @@
   // TOC starts where the first of these sections starts. We always create a
   // .got when we see a relocation that uses it, so for us the start is always
   // the .got.
-  uint64_t TocVA = In::Got->getVA();
+  uint64_t TocVA = In::Plt->getVA();
 
   // Per the ppc64-elf-linux ABI, The TOC base is TOC value plus 0x8000
   // thus permitting a full 64 Kbytes segment. Note that the glibc startup


would make any difference? It's not correct but might shed some light on what 
needs to be done
if I am right.

Could you explore this please?

Thanks, Roman

On Mon, Jan 16, 2017 at 05:18:34PM -0800, Mark Millard wrote:
> I found some wording relating older-style .got to newer style .got/.got.plt
> pair of sections (that need not be near each other). . .
> 
> https://sourceware.org/ml/binutils/2004-03/msg00350.html
> 
> says that the .got has been split in two: in essence the RELRO part
> and the non-RELRO part. Quoting:
> 
> > .got.plt section contains the 3 reserved entries plus the GOT entries
> > corresponding to the .plt stubs.  The point of separating this from
> > .got (where this lived at the beginning of .got, i.e.
> > .got : ( *(.got.plt) *(.got) ) in the linker script) is to put the reminder
> > of .got to an area which can be write protected after relocation is
> > finished because it is constant after relocation is finished.  This is not
> > true for .got.plt, which is written to during lazy binding.
> 
> That fits with what I've read about the end result that involves .got.plt .
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> On 2017-Jan-16, at 3:39 PM, Mark Millard  wrote:
> 
> > [Correcting a poor wording/interpetatation.]
> > 
> > On 2017-Jan-16, at 3:28 PM, Mark Millard  wrote:
> > 
> >> Looking up definitions of the section naming
> >> (using http://www.cs.stevens.edu/~jschauma/810/elf.html ). . .
> >> (Intel context)
> >> 
> >> 
> >> It looks like the RELRO segment (program header information) requires
> >> the .got section to be with the .ctors, .dtros, .jcr and such sections:
> >> .got is supposed to be inside the RELRO region. ld.lld output was using
> >> RELRO. Quoting the description of RELRO:
> >> 
> >> GNU_RELRO:
> >> 
> >> This segment indicates the memory region which should be made Read-Only 
> >> after relocation is done. This segment usually appears in a dynamic link 
> >> library and it contains .ctors, .dtors, .dynamic, .got sections. See 
> >> paragraph below.
> >> 
> >> BUT NOTE: The ld.lld output has .jcr section in the RELRO segment and the 
> >> .dynamic just after it.
> > 
> > That "BUT NOTE" is wrong because both .dynamic and .got were empty and so 
> > are not really outside
> > the RELRO region: just at the boundary. If they had some positive size then 
> > the end of RELRO
> > would be after those sections start and would include their content.
> > 
> >> Showing the objdump output for RELRO:
> >> 
> >>  RELRO off0x0002 vaddr 0x1002 paddr 
> >> 0x1002 align 2**0
> >>filesz 0x0138 memsz 0x0138 flags r--
> >> 
> >> .got.plt and .toc do not go in the RELRO segment.
> >> 
> >> 
> >> Quoting section descriptions. . .
> >> 
> >> 
> >> .rela.plt:
> >> 
> >> Runtime/Dynamic relocation table.
> >> This relocation table is similar to the one in .rela.dyn section; the 
> >> difference is this one is for functions, not variables.
> >> 
> >> The relocation type of entries in this table is R_386_JMP_SLOT or 
> >> R_X86_64_JUMP_SLOT and the "offset" refers to memory addresses which are 
> >> inside .got.plt section.
> >> 
> >> Simply put, this table holds information to relocate entries in .got.plt 
> >> section.
> >> 
> >> 
> >> .got:
> >> For dynamic binaries, this Global Offset Table holds the addresses of 
> >> variables which are relocated upon loading.
> >> 
> >> [Note: .got was empty because of a lack of global variables. But it
> >> was still present.]
> >> 
> >> 
> >> .got.plt:
> >> 
> >> For dynamic binaries, this Global Offset Table holds the addresses of 
> >> functions in dynamic libraries. They are used by trampoline code in .plt 
> >> section. If .got.plt section is present, it contains at least three 
> >> entries, which have special meanings.
> >> 
> >> 
> >> .toc:
> >> 
> >> Was not listed. (Likely powerpc64

[Bug 216166] graphics/gegl3: clang 4.0 crashes during build

2017-01-17 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216166

Dimitry Andric  changed:

   What|Removed |Added

   Assignee|freebsd-toolchain@FreeBSD.o |d...@freebsd.org
   |rg  |
URL||https://llvm.org/bugs/show_
   ||bug.cgi?id=31672

--- Comment #5 from Dimitry Andric  ---
Minimized a test case, and submitted it upstream as
https://llvm.org/bugs/show_bug.cgi?id=31672

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 216166] graphics/gegl3: clang 4.0 crashes during build

2017-01-17 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216166

Jan Beich (mail not working)  changed:

   What|Removed |Added

   Assignee|gn...@freebsd.org   |freebsd-toolchain@FreeBSD.o
   ||rg
  Flags|maintainer-feedback?(gnome@ |
   |FreeBSD.org)|

--- Comment #3 from Jan Beich (mail not working)  ---
Can you reproduce on /projects/clang400-import@312309 or devel/llvm-devel after
editing .sh file?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374

Re: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . .

Re: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374

[Bug 216166] graphics/gegl3: clang 4.0 crashes during build

[Bug 216166] graphics/gegl3: clang 4.0 crashes during build

6 matches

Site Navigation

Mail list logo

Footer information