Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS]

2017-01-07 Thread Mark Millard 
[Top post about FreeBSD bugzilla 215819 and llvm bugzilla
31574 submittals for the issue involved.]

My guess is that FreeBSD will view this as a kernel
source code issue and not as a toolchain issue. But
it is only a guess on my part.


I have submitted llvm bugzilla 31574 for this issue. It
includes example .S file content that shows the "problem"
in the generated .o file (form FreeBSD's view point).
(I've no clue how llvm views its criteria relative to this
mismatch with gcc/binutils.)

Because FreeBSD source code changes (being explicit about
@toc) avoid the distinction between clang and gcc/binutils
I've not added 31574 to the Depends on list for llvm 25780
(the FreeBSD system compiler issues META entry in llvm).

Someone with official status for FreeBSD could add 31574 to
llvm's 25780 if FreeBSD wants to push llvm to match
gcc/binutils for "@toc notation missing".

Otherwise this is a kernel source code issue (as I would
guess) and not a toolchain issue.

Ed Maste or someone like that likely would make the final
decision.


I've added to FreeBSD Bugzilla 215819 the new information,
including the simple example .S file content that shows the
problem in the generated .o file. (Comments #3 and #4
have the new material.)

My guess is that FreeBSD Bugzilla 215819 should no longer
be assigned to freebsd-toolchain@FreeBSD.org . Instead it
would be a powerpc64 kernel source code issue if I'm right.

Ed Maste or someone like that likely would make this final
decision as well.

===
Mark Millard
markmi at dsl-only.net

On 2017-Jan-7, at 3:12 PM, Mark Millard  wrote:

> [I've supplied a list of places that adding @toc notation should
> make clang 3.9.1 targeting powerpc64 do the right thing for
> this issue.]
> 
> On 2017-Jan-7, at 2:07 PM, Mark Millard  wrote:
> 
>> On 2017-Jan-7, at 12:51 AM, Roman Divacky  wrote:
>> 
>>> That's a great progress. Can you produce minimal self contained test case 
>>> that
>>> exhibits this bug? And submit it to llvm bugzilla?
>>> 
>>> Also, clang3.9 defaults to using it's own internal asm, what happens if you
>>> add -no-integrated-as to CFLAGS and recompile the kernel? That should remove
>>> this llvm assembly problem. Does it boot?
>>> 
>>> Thanks Mark, really great progress.
>>> 
>>> Roman
>> 
>> In attempting this I found how to control the behavior based on
>> the assembler notation @toc being missing vs. being present.
>> 
>> If llvm should change is strongly tied to llvm's criteria for
>> gcc compatibility relative to filling-in/defaulting omitted
>> @toc's in the assembler notation.
>> 
>> FreeBSD has the option of always being explicit with @toc in order
>> to avoid differences in handling of omitted notation.
>> 
>> So I've no clue if FreebSD wants to claim that a llvm change
>> is a requirement for using clang as the powerpc64 system compiler.
>> 
>> [The issue of the distinction is submittable to llvm either way.]
>> 
>> Details. . .
>> 
>> For:
>> 
>>   .section ".toc","aw"
>> tmpstk.L: .tc tmpstk[TC],tmpstk
>> . . .
>>   /* Set up the stack pointer */
>>   ld  %r1,tmpstk.L(%r2)
>> 
>> using devel/powerpc64-gcc gets:
>> 
>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ 
>>  
>>  
>>   -c \   
>>  
>>  
>>  
>>-x assembler-with-cpp \   
>>  
>>  
>>  -pipe  \
>>  
>>
  
> 
>>  
>> locore64_simplified.S
>> locore64_simplified.S: Assembler messages:
>> locore64_simplified.S:80: Warning: assuming @toc on symbol
>> 
>> and produces (with R_PPC64_TOC16_DS for .toc):
>> 
>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o
>> 
>> locore64_simplified.o: file format elf64-powerpc-freebsd
>> 
>> RELOCATION RECORDS FOR [.text]:
>> OFFSET   TYPE  VALUE 
>> 0028 R_PPC64_REL64 __tocbase+0x8000
>> 0046 R_PPC64_TOC16_DS  .toc
>> 
>> 
>> RELOCATION RECORDS FOR [.toc]:
>> OFFSET   TYPE  VALUE 
>>  R_PPC64_ADDR64tmpstk
>> 
>> 
>> RELOCATION RECORDS FOR [.opd]:
>> OFFSET

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS]

2017-01-07 Thread Mark Millard 
[I've supplied a list of places that adding @toc notation should
make clang 3.9.1 targeting powerpc64 do the right thing for
this issue.]

On 2017-Jan-7, at 2:07 PM, Mark Millard  wrote:

> On 2017-Jan-7, at 12:51 AM, Roman Divacky  wrote:
> 
>> That's a great progress. Can you produce minimal self contained test case 
>> that
>> exhibits this bug? And submit it to llvm bugzilla?
>> 
>> Also, clang3.9 defaults to using it's own internal asm, what happens if you
>> add -no-integrated-as to CFLAGS and recompile the kernel? That should remove
>> this llvm assembly problem. Does it boot?
>> 
>> Thanks Mark, really great progress.
>> 
>> Roman
> 
> In attempting this I found how to control the behavior based on
> the assembler notation @toc being missing vs. being present.
> 
> If llvm should change is strongly tied to llvm's criteria for
> gcc compatibility relative to filling-in/defaulting omitted
> @toc's in the assembler notation.
> 
> FreeBSD has the option of always being explicit with @toc in order
> to avoid differences in handling of omitted notation.
> 
> So I've no clue if FreebSD wants to claim that a llvm change
> is a requirement for using clang as the powerpc64 system compiler.
> 
> [The issue of the distinction is submittable to llvm either way.]
> 
> Details. . .
> 
> For:
> 
>.section ".toc","aw"
> tmpstk.L: .tc tmpstk[TC],tmpstk
> . . .
>/* Set up the stack pointer */
>ld  %r1,tmpstk.L(%r2)
> 
> using devel/powerpc64-gcc gets:
> 
> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \  
>   
>   
>-c \   
>   
>   
>   
> -x assembler-with-cpp \   
>   
>   
>-pipe  \   
>   
> 
   
>   
> locore64_simplified.S
> locore64_simplified.S: Assembler messages:
> locore64_simplified.S:80: Warning: assuming @toc on symbol
> 
> and produces (with R_PPC64_TOC16_DS for .toc):
> 
> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o
> 
> locore64_simplified.o: file format elf64-powerpc-freebsd
> 
> RELOCATION RECORDS FOR [.text]:
> OFFSET   TYPE  VALUE 
> 0028 R_PPC64_REL64 __tocbase+0x8000
> 0046 R_PPC64_TOC16_DS  .toc
> 
> 
> RELOCATION RECORDS FOR [.toc]:
> OFFSET   TYPE  VALUE 
>  R_PPC64_ADDR64tmpstk
> 
> 
> RELOCATION RECORDS FOR [.opd]:
> OFFSET   TYPE  VALUE 
>  R_PPC64_ADDR64.__start
> 0008 R_PPC64_TOC   *ABS*
> 
> 
> By contrast clang is silent (cross compiler used):
> 
> # 
> /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/cc 
> \ 
>   
>   -target powerpc64-unknown-freebsd12.0 \ 
>   
>   
>  
> --sysroot=/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp \ 
>   
>   
>
> -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin \ 
>   
>  
   
>   
> -c \  
>   
>   
>-x assembler-with-cpp 
> \

[Bug 215819] head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc

2017-01-07 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215819

--- Comment #3 from Mark Millard  ---
(In reply to Mark Millard from comment #0)

I found how to control the behavior based on
the assembler notation @toc being missing vs.
being present.

If llvm should change is strongly tied to llvm's criteria for
gcc compatibility relative to filling-in/defaulting omitted
@toc's in the assembler notation.

FreeBSD has the option of always being explicit with @toc in order
to avoid differences in handling of omitted notation.

So I've no clue if FreebSD wants to claim that a llvm change
is a requirement for using clang as the powerpc64 system compiler.

[The issue of the distinction is submittable to llvm either way.]

Details. . .

For:

   .section ".toc","aw"
tmpstk.L: .tc tmpstk[TC],tmpstk
. . .
   /* Set up the stack pointer */
   ld  %r1,tmpstk.L(%r2)

using devel/powerpc64-gcc gets:

# /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \   
  -c \ 
   
-x assembler-with-cpp \
  -pipe  \  
   
  locore64_simplified.S
locore64_simplified.S: Assembler messages:
locore64_simplified.S:80: Warning: assuming @toc on symbol

and produces (with R_PPC64_TOC16_DS for .toc):

# /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o

locore64_simplified.o: file format elf64-powerpc-freebsd

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE  VALUE 
0028 R_PPC64_REL64 __tocbase+0x8000
0046 R_PPC64_TOC16_DS  .toc


RELOCATION RECORDS FOR [.toc]:
OFFSET   TYPE  VALUE 
 R_PPC64_ADDR64tmpstk


RELOCATION RECORDS FOR [.opd]:
OFFSET   TYPE  VALUE 
 R_PPC64_ADDR64.__start
0008 R_PPC64_TOC   *ABS*


By contrast clang is silent (cross compiler used):

# /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/cc
\  -target
powerpc64-unknown-freebsd12.0 \
 
--sysroot=/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp \  
 
-B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin \   
   
  -c \-x assembler-with-cpp \  
   
-pipe  \   
  locore64_simplified.S

and produces code with R_PPC64_ADDR16_DS for the .toc instead:

# /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | more  
locore64_simplified.o: file format elf64-powerpc-freebsd

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE  VALUE 
0028 R_PPC64_REL64 __tocbase+0x8000
0046 R_PPC64_ADDR16_DS  .toc


RELOCATION RECORDS FOR [.toc]:
OFFSET   TYPE  VALUE 
 R_PPC64_ADDR64tmpstk


RELOCATION RECORDS FOR [.opd]:
OFFSET   TYPE  VALUE 
 R_PPC64_ADDR64.__start
0008 R_PPC64_TOC   *ABS*



But for:

   .section ".toc","aw"
tmpstk.L: .tc tmpstk[TC],tmpstk
. . .
   /* Set up the stack pointer */
   ld  %r1,tmpstk.L@toc(%r2)

(note the @toc notation) both compilers agree and use
R_PPC64_TOC16_DS for the .toc:

# /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \   
  -c \ 
   
-x assembler-with-cpp \
  -pipe  \  
   
  locore64_simplified.S

# /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | more  
locore64_simplified.o: file format elf64-powerpc-freebsd

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE  VALUE 
0028 R_PPC64_REL64 __tocbase+0x8000
0046 R_PPC64_TOC16_DS  .toc


RELOCATION RECORDS FOR [.toc]:
OFFSET   TYPE  VALUE 
 R_PPC64_ADDR64tmpstk


RELOCATION RECORDS FOR [.opd]:

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS]

2017-01-07 Thread Mark Millard 
On 2017-Jan-7, at 12:51 AM, Roman Divacky  wrote:

> That's a great progress. Can you produce minimal self contained test case that
> exhibits this bug? And submit it to llvm bugzilla?
> 
> Also, clang3.9 defaults to using it's own internal asm, what happens if you
> add -no-integrated-as to CFLAGS and recompile the kernel? That should remove
> this llvm assembly problem. Does it boot?
> 
> Thanks Mark, really great progress.
> 
> Roman

In attempting this I found how to control the behavior based on
the assembler notation @toc being missing vs. being present.

If llvm should change is strongly tied to llvm's criteria for
gcc compatibility relative to filling-in/defaulting omitted
@toc's in the assembler notation.

FreeBSD has the option of always being explicit with @toc in order
to avoid differences in handling of omitted notation.

So I've no clue if FreebSD wants to claim that a llvm change
is a requirement for using clang as the powerpc64 system compiler.

[The issue of the distinction is submittable to llvm either way.]

Details. . .

For:

.section ".toc","aw"
tmpstk.L: .tc tmpstk[TC],tmpstk
. . .
/* Set up the stack pointer */
ld  %r1,tmpstk.L(%r2)

using devel/powerpc64-gcc gets:

# /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \


 -c \   


  -x 
assembler-with-cpp \


  -pipe  \  

 

   locore64_simplified.S
locore64_simplified.S: Assembler messages:
locore64_simplified.S:80: Warning: assuming @toc on symbol

and produces (with R_PPC64_TOC16_DS for .toc):

# /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o

locore64_simplified.o: file format elf64-powerpc-freebsd

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE  VALUE 
0028 R_PPC64_REL64 __tocbase+0x8000
0046 R_PPC64_TOC16_DS  .toc


RELOCATION RECORDS FOR [.toc]:
OFFSET   TYPE  VALUE 
 R_PPC64_ADDR64tmpstk


RELOCATION RECORDS FOR [.opd]:
OFFSET   TYPE  VALUE 
 R_PPC64_ADDR64.__start
0008 R_PPC64_TOC   *ABS*


By contrast clang is silent (cross compiler used):

# /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/cc 
\   

  -target powerpc64-unknown-freebsd12.0 \   


   
--sysroot=/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp \   


 
-B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin \   

   

   -c \ 


-x assembler-with-cpp \ 



 -pipe  \

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS]

2017-01-07 Thread Roman Divacky 
That's a great progress. Can you produce minimal self contained test case that
exhibits this bug? And submit it to llvm bugzilla?

Also, clang3.9 defaults to using it's own internal asm, what happens if you
add -no-integrated-as to CFLAGS and recompile the kernel? That should remove
this llvm assembly problem. Does it boot?

Thanks Mark, really great progress.

Roman

On Thu, Jan 05, 2017 at 09:39:31PM -0800, Mark Millard wrote:
> [Summary: I tracked the boot code problem back to clang 3.9.x using 
> R_PPC64_ADDR16_DS
> with .toc in locore.o (that does not work) but xtoolchain using 
> R_PPC64_TOC16_DS
> with .toc in locore.o (that does work).]
> 
> On 2016-Dec-12, at 1:09 PM, Roman Divacky  wrote:
> 
> > Ping Can you take a look Nathan?
> > 
> > Thanks! Roman
> > 
> > On Thu, Dec 08, 2016 at 11:14:52PM +0100, Roman Divacky wrote:
> >> I believe the code comes from sys/powerpc/aim/locore64.S and if you compare
> >> the different values from the disssembly with the .S code you can see
> >> it's __tocbase and TOC_REF().
> >> 
> >> I wonder if the assembly has the -mminimal-toc knowledge hardcoded in 
> >> somehow.
> >> I am not sure what expectations the locore64.S has about the kernel layout 
> >> that
> >> we're probably breaking.
> >> 
> >> I've CCed Nathan Whitehorn. Nathan, can you take a look please?
> >> 
> >> Thanks, Roman
> >> 
> >> On Thu, Dec 08, 2016 at 02:03:58PM -0800, Mark Millard wrote:
> >>> [I have dropped the patch related information and just have
> >>> failing-boot related information here.]
> >>> 
> >>> On 2016-Dec-8, at 10:55 AM, Roman Divacky  wrote:
> >>> 
>  Can you try to investigate why it dies? I am not convinced -mminimal-toc
>  would result in a boot failure. I think the kernel would fail to link.
> >>> 
> >>> I give information for both devel/powerpc64-binutils based
> >>> and for WITH_BINUTILS_BOOTSTRAP= based. They are different.
> >>> 
> >>> For using 2.25.1 of devel/powerpc64-binutils (a cross build):
> >>> (from camera image of screen)
> >>> 
> >>> . . . (omitted material) . . .
> >>> Type '?' for a list of commands, 'help' for more detailed help.
> >>> OK unload
> >>> OK boot ker390
> >>> /boot/ker390/kernel data=0xf851a8+0x42dd98 syms=[0x8+0xd6848+0x8+0xf1137]
> >>> /boot/entropy size=0x1000
> >>> Booting. . .
> >>> Kernel entry at 0x100160
> >>> 
> >>> Invalid memory access at   %SSR0: .001001b0   
> >>> %SRR1:9000.3030
> >>> 
> >>> Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03
> >>> . . . (omitted material) . . .
> >>> ok
> >>> 0 >
> >>> 
> >>> The only options at this point are:
> >>> 
> >>> mac-boot
> >>> shut-down
> >>> 
> >>> 
> >>> From objdump for the above failing boot
> >>> but with notes added:
> >>> (Note: booting xtoolchain kernel starts at
> >>>   00100120 instead; relative
> >>>   offsets are unchanged and the code
> >>>   is mostly the same.)
> >>> 
> >>> Disassembly of section .text:
> >>> 00100160 <.__start> mfmsr   r20
> >>> 00100164 <.__start+0x4> li  r21,1
> >>> 00100168 <.__start+0x8> rldimi  r20,r21,63,0
> >>> 0010016c <.__start+0xc> mtmsrd  r20
> >>> 00100170 <.__start+0x10> isync
> >>> 00100174 <.__start+0x14> nop
> >>> 00100178 <.__start+0x18> b   00100180 <.__start+0x20>
> >>> 0010017c <.__start+0x1c> nop
> >>> 00100180 <.__start+0x20> nop
> >>> 00100184 <.__start+0x24> bl  00100190 <.__start+0x30>
> >>> 00100188 <.__start+0x28> .long 0x0
> >>> 0010018c <.__start+0x2c> .long 0xf8ce78
> >>>  booting xtoolchain based kernel has: 0xfebeb8 above<<<=== note
> >>> 00100190 <.__start+0x30> mflrr2
> >>> 00100194 <.__start+0x34> ld  r1,0(r2)
> >>> 00100198 <.__start+0x38> add r2,r1,r2
> >>> 0010019c <.__start+0x3c> ld  r31,-32768(r2)
> >>> 001001a0 <.__start+0x40> subfr31,r31,r2
> >>> 001001a4 <.__start+0x44> ld  r1,0(r2)<<<=== !
> >>>  booting xtoolchain based kernel has:   r1,-32760(r2) above <<<=== !
> >>> 001001a8 <.__start+0x48> addir1,r1,16288
> >>> 001001ac <.__start+0x4c> add r1,r1,r31
> >>> 001001b0 <.__start+0x50> std r3,48(r1)
> >>>  SRR0 points at the above instruction
> >>> (I stopped comparing to the booting xtoolchain
> >>> based code after this.)
> >>> 001001b4 <.__start+0x54> std r4,56(r1)
> >>> 001001b8 <.__start+0x58> std r5,64(r1)
> >>> 001001bc <.__start+0x5c> std r6,72(r1)
> >>> 001001c0 <.__start+0x60> bl  001001cc <.__start+0x6c>
> >>> 001001c4 <.__start+0x64> .long 0x0
> >>> 001001c8 <.__start+0x68> .long 0xf84ed4
> >>> 001001cc <.__start+0x6c> mflrr3
> >>> 001001d0 <.__start+0x70> ld  r4,0(r3)
> >>> 001001d4 <.__start+0x74> add r3,r4,r3
> >>> 001001d8 <.__start+0x78> mr  r4,r31
> >>>