Bug 239222 - Why is my function descriptor ending up in BSS?
Why is my function descriptor ending up in BSS?
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: binutils (Show other bugs)
rawhide
ppc64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks: 239077
  Show dependency treegraph
 
Reported: 2007-05-06 08:28 EDT by David Woodhouse
Modified: 2008-08-02 19:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-10 08:26:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test case (1.57 MB, application/octet-stream)
2007-05-06 08:30 EDT, David Woodhouse
no flags Details
parser.s (651.20 KB, text/plain)
2007-05-06 18:32 EDT, David Woodhouse
no flags Details
pervasives.s (66.42 KB, text/plain)
2007-05-06 18:33 EDT, David Woodhouse
no flags Details

  None (edit)
Description David Woodhouse 2007-05-06 08:28:51 EDT
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 08:30:51 EDT
Created attachment 154225 [details]
test case
Comment 2 Jakub Jelinek 2007-05-06 12:55:55 EDT
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 18:32:16 EDT
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 18:32:59 EDT
Created attachment 154232 [details]
parser.s
Comment 5 David Woodhouse 2007-05-06 18:33:53 EDT
Created attachment 154233 [details]
pervasives.s
Comment 6 David Woodhouse 2007-05-06 19:04:31 EDT
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 07:46:24 EDT
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 08:12:56 EDT
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 08:26:45 EDT
Yeah, your interpretation was certainly correct, nevertheless there was a linker
bug which I fixed.  Closing as UPSTREAM.

Note You need to log in before you can comment on or make changes to this bug.