Bug 239222

Summary: Why is my function descriptor ending up in BSS?
Product: [Fedora] Fedora Reporter: David Woodhouse <dwmw2>
Component: binutilsAssignee: Jakub Jelinek <jakub>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: dev
Target Milestone: ---   
Target Release: ---   
Hardware: ppc64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-05-10 12:26:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 239077    
Attachments:
Description Flags
test case
none
parser.s
none
pervasives.s none

Description David Woodhouse 2007-05-06 12:28:51 UTC 
See attached tarball. There is caml_alloc() function, provided by asmrun/alloc.c.
The caml_alloc() function is in stdlib/libasmrun.a, which is linked into the
executable. There is no other caml_alloc.

So why is caml_alloc in BSS in the output? And why are we just jumping to it...

Starting program: /home/dwmw2/bz/ocamlopt.opt 

Program received signal SIGSEGV, Segmentation fault.
0x0000000010208bd0 in caml_alloc ()
(gdb) x/10i $pc
0x10208bd0 <caml_alloc>:        .long 0x0
0x10208bd4 <caml_alloc+4>:      .long 0x0
0x10208bd8 <caml_alloc+8>:      .long 0x0
0x10208bdc <caml_alloc+12>:     .long 0x0


The actual patches we have to attempt to get ocaml to build on ppc64 are
available elsewhere; when we understand why this linker strangeness is happening
we can make some more progress...
Comment 1 David Woodhouse 2007-05-06 12:30:51 UTC 
Created attachment 154225 [details]
test case
Comment 2 Jakub Jelinek 2007-05-06 16:55:55 UTC 
Can I see assembly for stdlib.a's pervasives.s and parsing/parser.s?
To me this looks like the compiler is either not ported to ppc64 at all
or extremely badly.  ppc64 code shouldn't be using R_PPC64_ADDR16_{HA,HI,LO}
relocations at all, ppc64 code is supposed to be position independent always
and is supposed to use TOC and access to TOC, while this CAML stuff uses
heavily these normally ppc32 relocations for non-pic code, which e.g. assume
code in low 2 resp. 4GB of address space, etc.
The reason why caml_alloc and caml_sys_exit end up in .dynbss section
is exactly this, there are non-got references to it and the linker never handled
that well, as it is never produced in ppc64 code.
Comment 3 David Woodhouse 2007-05-06 22:32:16 UTC 
The compiler is indeed not ported to ppc64 very well -- we're working on that. 

The patch at http://dev.nigelj.com/ocaml-3.09.3.ppc64.patch was Nigel's start,
based on existing Rhapsody PPC64 code. The first SEGV was when caml_c_call()
jumped into the function descriptor -- after fixing that (with a quick hack
which doesn't load the TOC pointer yet), the next SEGV was caml_alloc_array()
jumping into BSS when it should have been calling caml_alloc(). At which point I
got confused.
Comment 4 David Woodhouse 2007-05-06 22:32:59 UTC 
Created attachment 154232 [details]
parser.s
Comment 5 David Woodhouse 2007-05-06 22:33:53 UTC 
Created attachment 154233 [details]
pervasives.s
Comment 6 David Woodhouse 2007-05-06 23:04:31 UTC 
So, if we fix the code in asmcomp/power64/ to use the TOC properly instead of
absolute references, the linker strangeness is expected to go away?
Comment 7 Jakub Jelinek 2007-05-10 11:46:24 UTC 
The original linker bug is now fixed upstream, do you still need it in F7 or can
it wait for F8?
Comment 8 David Woodhouse 2007-05-10 12:12:56 UTC 
Er, I don't think I need it in F7; thanks. I interpreted it as a 'don't do that
then' and we're working on fixing the ML compiler to use the TOC instead.
Comment 9 Jakub Jelinek 2007-05-10 12:26:45 UTC 
Yeah, your interpretation was certainly correct, nevertheless there was a linker
bug which I fixed.  Closing as UPSTREAM.