FAQ
Hi everyone..

If anyone has a spare minute to review the my patch which ports Open64
to OpenSolaris snv_107+. It also contains most (not all) of the changes
to complete the FreeBSD port.

http://pkg.osunix.org/open64/open64-opensolaris-fbsd-merged-3-3.diff.gz

342 files changed
258K open64-opensolaris-fbsd-merged-3-3.diff
Built with gcc version 4.4.0 20090130 (experimental) (GCC)


Questions:
1) Best way to replace /proc/cpuinfo for OpenSolaris?

opencc -v
opencc WARNING: cannot read /proc/cpuinfo, defaulting to basic 32-bit x86.
sh: line 1: /usr/local/src/bar/open64/usr/bin/gcc: not found
opencc ERROR: no support for GCC version 0
sh: line 1: /usr/local/src/bar/open64/usr/bin/gcc: not found
opencc INTERNAL ERROR: display_version: unexpected GCC version 0

Open64 Compiler Suite: Version 7.40
Built on: 2009-03-03 00:32:55 +0200
Thread model: posix
GNU gcc version 3.3.1 (Open64 4.2 driver)

Should I just #ifdef?
osprey/driver/opt_actions.c

2) The patch comments out building ld-new. This needs to be fixed, but
what's the best way to do this on OpenSolaris only?

3) Instead of creating solaris include directly I #ifdef elf_stuff and
friends. Better way?

4) I'd say 99% of the FreeBSD port is also included in this patch, but I
was thinking to do the OpenSolaris port first and then in another patch
finish the FreeBSD port

5) Need to detect OpenSolaris in the Makefile* so it calls hostname
instead of hostname -f

6) The FreeBSD port work I merged had. I reverted, but thoughts?

- UINT64 esize = Get_Integer_Value (newesize) / BITSPERBYTE;
+ UINT64 esize = Get_Integer_Value (newesize) / BITSPERBYTE;

7) I didn't confirm, but ksh93 as /bin/sh causes a corruption on
preg_list.h file creation


Thanks

./Christopher


ps.. Anyone with SPEC2006 feel like helping with some benchmarks?

Search Discussions

  • John Martin at Mar 3, 2009 at 12:13 am

    C. Bergstr?m wrote:

    1) Best way to replace /proc/cpuinfo for OpenSolaris?

    opencc -v
    opencc WARNING: cannot read /proc/cpuinfo, defaulting to basic 32-bit
    x86.
    This code is looking for the plain text processor description, e.g.
    "Intel(R) Core(TM) i7". On Solaris this can be fetched with smbios.
    I don't know the stability of the interfaces in libsmbios.so.1. I can
    investigate this later this week.
  • Rayson Ho at Mar 3, 2009 at 2:10 am

    On Mon, Mar 2, 2009 at 7:13 PM, John Martin wrote:
    1) Best way to replace /proc/cpuinfo for OpenSolaris?

    opencc -v
    opencc WARNING: cannot read /proc/cpuinfo, defaulting to basic 32-bit x86.
    This code is looking for the plain text processor description, e.g.
    "Intel(R) Core(TM) i7". On Solaris this can be fetched with smbios.
    Another way is to fetch the information from "/dev/cpu/self/cpuid":

    http://blogs.sun.com/JoeBonasera/entry/detecting_hardware_virtualization_support_for

    I got the program in the blog entry compiled on snv_86 without any
    modification. I believe the interface should be stable, as it is
    basically returning the information from the CPUID instruction.
    However, we can easily change the code to execute CPUID directly using
    inline assembly if we want to.

    Also, with the information returned from "/dev/cpu/self/cpuid" or
    CPUID, we can check for the bits set for any specific hardware
    features, eg. AMD or Intel, support level of MMX or SSEx, 32 or
    64-bit, etc.

    http://en.wikipedia.org/wiki/CPUID

    2) The patch comments out building ld-new. This needs to be fixed, but
    what's the best way to do this on OpenSolaris only?
    So are we planning to use the native Solaris linker??

    Rayson


    I don't know the stability of the interfaces in libsmbios.so.1. I can
    investigate this later this week.

    _______________________________________________
    hpcdev-discuss mailing list
    hpcdev-discuss@opensolaris.org
    http://mail.opensolaris.org/mailman/listinfo/hpcdev-discuss
  • Christopher Bergström at Mar 3, 2009 at 7:52 am

    Rayson Ho wrote:
    On Mon, Mar 2, 2009 at 7:13 PM, John Martin wrote:

    1) Best way to replace /proc/cpuinfo for OpenSolaris?

    opencc -v
    opencc WARNING: cannot read /proc/cpuinfo, defaulting to basic 32-bit x86.
    This code is looking for the plain text processor description, e.g.
    "Intel(R) Core(TM) i7". On Solaris this can be fetched with smbios.
    Another way is to fetch the information from "/dev/cpu/self/cpuid":

    http://blogs.sun.com/JoeBonasera/entry/detecting_hardware_virtualization_support_for
    That's CDDL code.. can't include it with GPL, but otherwise it's exactly
    what we need.
    2) The patch comments out building ld-new. This needs to be fixed, but
    what's the best way to do this on OpenSolaris only?
    So are we planning to use the native Solaris linker??
    I assume the linker included is just gnu ld? If so there's numerous
    benefits to using sun ld. Unless there's a compelling reason not to I
    say comment it out for Solaris and use sun ld by default.



    ./C
  • Jian-Xin Lai at Mar 3, 2009 at 8:07 am
    ld-new is based on gnu ld and used as the ipa linker. It's only used if IPA
    is enabled. Open64 always use the system ld(or system gcc) as the final
    linker by default.

    2009/3/3 "C. Bergström" <cbergstrom@netsyncro.com>
    2) The patch comments out building ld-new. This needs to be fixed, but
    what's the best way to do this on OpenSolaris only?
    So are we planning to use the native Solaris linker??
    I assume the linker included is just gnu ld? If so there's numerous
    benefits to using sun ld. Unless there's a compelling reason not to I
    say comment it out for Solaris and use sun ld by default.



    ./C
    - 显示引用文字 -



    ------------------------------------------------------------------------------
    Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
    CA
    -OSBC tackles the biggest issue in open source: Open Sourcing the
    Enterprise
    -Strategies to boost innovation and cut costs with open source
    participation
    -Receive a $600 discount off the registration fee with the source code:
    SFAD
    http://p.sf.net/sfu/XcvMzF8H
    _______________________________________________
    Open64-devel mailing list
    Open64-devel@lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/open64-devel


    --
    Regards,
    Lai Jian-Xin
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/osunix-dev/attachments/20090303/5b200efd/attachment.htm
  • Rayson Ho at Mar 6, 2009 at 6:22 am
    Jian-Xin:

    Is there anything modified in "ld-new"?? How is it different from the
    GNU linker??

    I assume the object files with IPA information (WHIRL sections?) need
    special treatment... but I am hoping that we can workaround the issues
    and use the system linker to reduce maintenance effort...


    Christopher:

    I very quickly went through the diff, most of the changes are #defines
    for solaris. Except a few places I need to further investigate I think
    most of the code is good!

    I have some questions:

    - is the diff against the open64 src tarball or from cvs HEAD??

    - are you able to get HelloWorld compiled yet??

    Rayson

    P.S. talking about Google summer of Code, I still need to see what we
    want for SGE: http://wiki.gridengine.info/wiki/index.php/GSoCIdeas



    On Tue, Mar 3, 2009 at 3:07 AM, Jian-Xin Lai wrote:
    ld-new is based on gnu ld and used as the ipa linker. It's only used if IPA
    is enabled. Open64 always use the system ld(or system gcc) as the final
    linker by default.

    2009/3/3 "C. Bergstr?m" <cbergstrom@netsyncro.com>
    2) The patch comments out building ld-new. This needs to be fixed, but
    what's the best way to do this on OpenSolaris only?
    So are we planning to use the native Solaris linker??
    I assume the linker included is just gnu ld? If so there's numerous
    benefits to using sun ld. Unless there's a compelling reason not to I
    say comment it out for Solaris and use sun ld by default.



    ./C
    - ?????? -


    ------------------------------------------------------------------------------
    Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
    CA
    -OSBC tackles the biggest issue in open source: Open Sourcing the
    Enterprise
    -Strategies to boost innovation and cut costs with open source
    participation
    -Receive a $600 discount off the registration fee with the source code:
    SFAD
    http://p.sf.net/sfu/XcvMzF8H
    _______________________________________________
    Open64-devel mailing list
    Open64-devel@lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/open64-devel


    --
    Regards,
    Lai Jian-Xin
  • Christopher Bergström at Mar 6, 2009 at 7:24 am

    Rayson Ho wrote:
    Jian-Xin:

    Is there anything modified in "ld-new"?? How is it different from the
    GNU linker??

    I assume the object files with IPA information (WHIRL sections?) need
    special treatment... but I am hoping that we can workaround the issues
    and use the system linker to reduce maintenance effort...


    Christopher:

    I very quickly went through the diff, most of the changes are #defines
    for solaris. Except a few places I need to further investigate I think
    most of the code is good!

    I have some questions:

    - is the diff against the open64 src tarball or from cvs HEAD??

    - are you able to get HelloWorld compiled yet??
    Hi Rayson,

    HelloWorld did not work for me for a few of reasons..

    1) The gmake install did not seem to work correctly and complained later
    that it couldn't find gcc.. (Making that symlink to gcc-4.4 == bad I
    think ;)
    2) I'm using gcc-4.4 experimental since that is what I easily had
    available on OpenSolaris
    3) From a gmake clean and then going back to fix the compile issues with
    ld-new was minimal.. I can make a new diff if you want
    4) The diff is against svn head Revision: 2105
    https://svn.open64.net/svnroot/open64/trunk


    Thanks for looking at the patch.. I have this feeling if I use
    gcc-3.4-4.1 + pull the CPUID bits from mplayer it'll work.. Not sure
    though..


    ./C
  • Jian-Xin Lai at Mar 6, 2009 at 7:46 am
    If you do not need to enable IPA, the whole ld-new and other IPA related
    stuffs ( all files in osprey/ipa ) can be ignored.

    If IPA is needed, the ld-new must be migrated because the system ld does not
    know WHIRL related sections at all.
    The ld-new ( osprey/cygnus ) is based on gnu binutils-2.16.1. I do know if
    gnu ld is compatible with the OpenSolaris ld.
    But it should not be trouble because the output of ld-new will be fed into
    Open64 backend. Then the Open64 driver will
    call the system ld to do the final linking.

    2009/3/6 Rayson Ho <raysonlogin@gmail.com>
    Jian-Xin:

    Is there anything modified in "ld-new"?? How is it different from the
    GNU linker??

    I assume the object files with IPA information (WHIRL sections?) need
    special treatment... but I am hoping that we can workaround the issues
    and use the system linker to reduce maintenance effort...


    Christopher:

    I very quickly went through the diff, most of the changes are #defines
    for solaris. Except a few places I need to further investigate I think
    most of the code is good!

    I have some questions:

    - is the diff against the open64 src tarball or from cvs HEAD??

    - are you able to get HelloWorld compiled yet??

    Rayson

    P.S. talking about Google summer of Code, I still need to see what we
    want for SGE: http://wiki.gridengine.info/wiki/index.php/GSoCIdeas



    On Tue, Mar 3, 2009 at 3:07 AM, Jian-Xin Lai wrote:
    ld-new is based on gnu ld and used as the ipa linker. It's only used if IPA
    is enabled. Open64 always use the system ld(or system gcc) as the final
    linker by default.

    2009/3/3 "C. Bergström" <cbergstrom@netsyncro.com>
    2) The patch comments out building ld-new. This needs to be fixed,
    but
    what's the best way to do this on OpenSolaris only?
    So are we planning to use the native Solaris linker??
    I assume the linker included is just gnu ld? If so there's numerous
    benefits to using sun ld. Unless there's a compelling reason not to I
    say comment it out for Solaris and use sun ld by default.



    ./C
    - 显示引用文字 -

    ------------------------------------------------------------------------------
    Open Source Business Conference (OSBC), March 24-25, 2009, San
    Francisco,
    CA
    -OSBC tackles the biggest issue in open source: Open Sourcing the
    Enterprise
    -Strategies to boost innovation and cut costs with open source
    participation
    -Receive a $600 discount off the registration fee with the source code:
    SFAD
    http://p.sf.net/sfu/XcvMzF8H
    _______________________________________________
    Open64-devel mailing list
    Open64-devel@lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/open64-devel


    --
    Regards,
    Lai Jian-Xin


    --
    Regards,
    Lai Jian-Xin
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/osunix-dev/attachments/20090306/d999ed0e/attachment.htm
  • John Martin at Mar 3, 2009 at 1:05 pm

    Rayson Ho wrote:
    On Mon, Mar 2, 2009 at 7:13 PM, John Martin wrote:

    1) Best way to replace /proc/cpuinfo for OpenSolaris?

    opencc -v
    opencc WARNING: cannot read /proc/cpuinfo, defaulting to basic 32-bit x86.
    This code is looking for the plain text processor description, e.g.
    "Intel(R) Core(TM) i7". On Solaris this can be fetched with smbios.
    Another way is to fetch the information from "/dev/cpu/self/cpuid":

    http://blogs.sun.com/JoeBonasera/entry/detecting_hardware_virtualization_support_for

    I got the program in the blog entry compiled on snv_86 without any
    modification. I believe the interface should be stable, as it is
    basically returning the information from the CPUID instruction.
    However, we can easily change the code to execute CPUID directly using
    inline assembly if we want to.

    Also, with the information returned from "/dev/cpu/self/cpuid" or
    CPUID, we can check for the bits set for any specific hardware
    features, eg. AMD or Intel, support level of MMX or SSEx, 32 or
    64-bit, etc.

    http://en.wikipedia.org/wiki/CPUID
    The code in question wants the SMBIOS Vendor string for the CPU.
    Is this available through one of the CPUID functions?

    Otherwise we would would need to rearrange the code to parse
    the instruction capability bits, which is what the upstream code is
    after anyway.
  • Christopher Bergström at Mar 3, 2009 at 2:03 pm

    John Martin wrote:
    Rayson Ho wrote:
    On Mon, Mar 2, 2009 at 7:13 PM, John Martin <John.M.Martin@sun.com>
    wrote:
    1) Best way to replace /proc/cpuinfo for OpenSolaris?

    opencc -v
    opencc WARNING: cannot read /proc/cpuinfo, defaulting to basic
    32-bit x86.
    This code is looking for the plain text processor description, e.g.
    "Intel(R) Core(TM) i7". On Solaris this can be fetched with smbios.
    Another way is to fetch the information from "/dev/cpu/self/cpuid":

    http://blogs.sun.com/JoeBonasera/entry/detecting_hardware_virtualization_support_for


    I got the program in the blog entry compiled on snv_86 without any
    modification. I believe the interface should be stable, as it is
    basically returning the information from the CPUID instruction.
    However, we can easily change the code to execute CPUID directly using
    inline assembly if we want to.

    Also, with the information returned from "/dev/cpu/self/cpuid" or
    CPUID, we can check for the bits set for any specific hardware
    features, eg. AMD or Intel, support level of MMX or SSEx, 32 or
    64-bit, etc.

    http://en.wikipedia.org/wiki/CPUID
    The code in question wants the SMBIOS Vendor string for the CPU.
    Is this available through one of the CPUID functions?

    Otherwise we would would need to rearrange the code to parse
    the instruction capability bits, which is what the upstream code is
    after anyway.
    Hi John,

    This code has exactly what we want and may be more portable. (Along with
    if we change it minimally to fit our need we can just continue to merge
    changes.)

    http://svn.mplayerhq.hu/mplayer/trunk/cpuinfo.c?view=markup


    Tracing this back will show how they extracted it..
    idstr[12] = 0;
    printf("vendor_id\t: %s\n", idstr);

    I have two slightly bigger problems though..

    1) I need to refocus this week so I can start to help write up the gsoc
    projects (not just open64)

    2) ....

    dbx - core
    Corefile specified executable:
    "/usr/local/src/bar/open64/lib/gcc-lib/x86_64-open64-freebsd/4.2/wgen42"
    For information about new features see `help changes'
    To remove this message, put `dbxenv suppress_startup_message 7.7' in
    your .dbxrc
    Reading wgen42
    core file header read successfully
    Reading ld.so.1
    Reading libstdc++.so.6.0.11

    dbx: internal error: signal SIGSEGV (no mapping at the fault address)
    dbx's coredump will appear in /tmp
    Abort (core dumped)

    Anyone who can test the patch or look for errors?

    Thanks

    ./C
  • Rayson Ho at Mar 3, 2009 at 4:34 pm

    On Tue, Mar 3, 2009 at 9:03 AM, "C. Bergstr?m" wrote:
    This code has exactly what we want and may be more portable. (Along with if
    we change it minimally to fit our need we can just continue to merge
    changes.)

    http://svn.mplayerhq.hu/mplayer/trunk/cpuinfo.c?view=markup
    Ah, looks good. Didn't know that someone has already written code to
    parse the CPUID information in a form that is mostly reusable. Then I
    guess we should use the code as the license is compatible with Open64.

    If we were to start from scratch, I would use read
    "/dev/cpu/self/cpuid" (see:
    http://docs.sun.com/app/docs/doc/819-2254/cpuid-7d?a=view ) so that
    the port to SPARC is a bit easier. However, getting Open64 to generate
    SPARC code is at least 10 times more work than the current port, and I
    believe whoever wants to get the SPARC port done wonldn't mind writing
    an extra few more lines of new code :)


    Also:
    - I've downloaded the patch but have not started to review it yet... I
    will do it soon!
    - what exactly is the problem of point number 2 (below)??

    Rayson



    Tracing this back will show how they extracted it..
    idstr[12] = 0;
    printf("vendor_id\t: %s\n", idstr);

    I have two slightly bigger problems though..

    1) I need to refocus this week so I can start to help write up the gsoc
    projects (not just open64)

    2) ....

    dbx - core
    Corefile specified executable:
    "/usr/local/src/bar/open64/lib/gcc-lib/x86_64-open64-freebsd/4.2/wgen42"
    For information about new features see `help changes'
    To remove this message, put `dbxenv suppress_startup_message 7.7' in your
    .dbxrc
    Reading wgen42
    core file header read successfully
    Reading ld.so.1
    Reading libstdc++.so.6.0.11

    dbx: internal error: signal SIGSEGV (no mapping at the fault address)
    dbx's coredump will appear in /tmp
    Abort (core dumped)

    Anyone who can test the patch or look for errors?

    Thanks

    ./C

  • Christopher Bergström at Mar 3, 2009 at 6:50 pm

    Rayson Ho wrote:
    On Tue, Mar 3, 2009 at 9:03 AM, "C. Bergstr?m" wrote:

    This code has exactly what we want and may be more portable. (Along with if
    we change it minimally to fit our need we can just continue to merge
    changes.)

    http://svn.mplayerhq.hu/mplayer/trunk/cpuinfo.c?view=markup
    Ah, looks good. Didn't know that someone has already written code to
    parse the CPUID information in a form that is mostly reusable. Then I
    guess we should use the code as the license is compatible with Open64.

    If we were to start from scratch, I would use read
    "/dev/cpu/self/cpuid" (see:
    http://docs.sun.com/app/docs/doc/819-2254/cpuid-7d?a=view ) so that
    the port to SPARC is a bit easier. However, getting Open64 to generate
    SPARC code is at least 10 times more work than the current port, and I
    believe whoever wants to get the SPARC port done wonldn't mind writing
    an extra few more lines of new code :)


    Also:
    - I've downloaded the patch but have not started to review it yet... I
    will do it soon!
    - what exactly is the problem of point number 2 (below)??
    Oh.. nothing too big.. just that it dumps core and and then the debugger
    dumps core trying to debug it... and I completely agree whoever is
    porting the whole thing to sparc will not mind the extra code.. Look
    forward to your comments...

    ./C
  • Rayson Ho at Mar 3, 2009 at 7:07 pm

    On Tue, Mar 3, 2009 at 1:50 PM, "C. Bergstr?m" wrote:
    Oh.. nothing too big.. just that it dumps core and and then the debugger
    dumps core trying to debug it...
    If you compile with gcc, then it is easier to debug with gdb. Usually
    the debugging info (DWARF) generated by gcc can be easily consumed by
    gdb...

    Rayson



    and I completely agree whoever is porting
    the whole thing to sparc will not mind the extra code.. Look forward to
    your comments...

    ./C


  • Christopher Bergström at Mar 11, 2009 at 6:57 am
    Just wanted to share a quick update with everyone..

    With some help from Rayson we're down to the last parts

    1) Fix segfault with ipa (I suspect FreeBSD/OpenSolaris)
    2) Minor linker change (Sun ld only)
    3) CPUID for platforms without /proc/cpuinfo (FreeBSD/OpenSolaris)
    4) Makefile clean-up

    Anyone who wants to help can email me and I'll set them up with ssh access.
    -----------------

    Here's the patch against current svn.
    http://pkg.osunix.org/open64/open64-opensolaris-fbsd-merged-3-12.diff.gz

    ------------------

    Currently adding -ipa will dump core

    /usr/local/src/bar/open64/usr/lib/ipl -PHASE:p:i -O2 -show -TARG:abi=n32
    -LANG:cxx_openmp=on -LANG:=ansi_c -fB,hello.B -fo,hello.o hello.c -cmds
    opencc -show -TARG:abi=n32 -TARG:processor=anyx86 -TARG:sse2=off
    -TARG:mmx=off -TARG:sse=off -TARG:sse3=off -TARG:3dnow=off -TARG:sse4a=off

    core file:
    http://pkg.osunix.org/open64/error-core


    Stack:
    where
    [1] kill(0x5e09, 0x4, 0xffffff022a6360c0, 0xffffdd7fff5037aa, 0x50,
    0xfb0), at 0xffffdd7fff50389a
    =>[2] ErrMsg_Report_User(edesc = 0x42d7f0, ecode = 1010, line = 0, file
    = (nil), vp = 0xfffffd7fffdfed00), line 1148 in "errors.cxx"
    [3] ErrMsg_Report(ecode = 1010, line = 0, file = (nil), vp =
    0xfffffd7fffdfed00), line 1175 in "errors.cxx"
    [4] ErrMsgLine(ecode = 1010, line = 0, ...), line 1221 in "errors.cxx"
    [5] catch_signal(sig = 11, error_num = 0), line 305 in "errors.cxx"
    [6] __sighndlr(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffdd7fff4fae46
    [7] call_user_handler(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at
    0xffffdd7fff4ee00f
    [8] sigacthandler(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffdd7fff4ee21e
    ---- called from signal handler with signal 11 (SIGSEGV) ------
    [9] 0x0(0xb, 0x439220, 0x0, 0x1, 0x0, 0xffffdd7fffdfb650), at 0x0
    [10] load_components(argc = 21, argv = 0xfffffd7fffdff3a8), line 509
    in "driver.cxx"
    [11] main(argc = 21, argv = 0xfffffd7fffdff3a8), line 2244 in "driver.cxx"
    ---------
    Linker should pass -R instead of -rpath-link

    /opt/gcc/gcc-4.1/libexec/gcc/i386-pc-solaris2.11/4.1.2/collect2 -V -Y
    P,/usr/ccs/lib:/usr/lib -Qy /usr/lib/crt1.o /usr/lib/crti.o
    /usr/lib/values-Xa.o
    /opt/gcc/gcc-4.1/lib/gcc/i386-pc-solaris2.11/4.1.2/crtbegin.o
    -L/usr/local/src/bar/open64//usr/lib/32
    -L/opt/gcc/gcc-4.1/lib/gcc/i386-pc-solaris2.11/4.1.2
    -L/opt/gcc/gcc-4.1/lib/gcc/i386-pc-solaris2.11/4.1.2/../../..
    -rpath-link /usr/local/src/bar/open64//usr/lib/32 hello.o -lgcc -lgcc_eh
    -lc -lgcc -lgcc_eh
    /opt/gcc/gcc-4.1/lib/gcc/i386-pc-solaris2.11/4.1.2/crtend.o /usr/lib/crtn.o
    ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1641
    ld: elf error: file /usr/local/src/bar/open64//usr/lib/32: elf_begin:
    I/O error: region read: Is a directory
    ld: fatal: file processing errors. No output written to a.out
    collect2: ld returned 1 exit status


    With that change the hello world will link and run..

    Hope I haven't made too much noise..


    Thanks

    ./Christopher

    ----

    Community driven OpenSolaris Technology - http://www.osunix.org
    blog: http://www.codestrom.com
  • Rayson Ho at Mar 16, 2009 at 11:36 pm
    Open64 can finally compile HelloWorld at -ipa.

    There are still a few steps that need to be done "by hand", including
    hand modifying the makefile in the final make phrase. And Solaris'
    make does not like the ".IGNORE" directive in the makefile, so it's
    likely that we will require the user to install the GNU toolchain
    before installing Open64...

    There is still lots of work to be done, but most of them are just path
    of things not right, and things like the Solaris linker flags not
    compatible with the Linux linker flags, etc... luckily so far most of
    the issues do not require major code changes.

    Rayson



    On Wed, Mar 11, 2009 at 1:57 AM, "C. Bergstr?m"
    wrote:
    Just wanted to share a quick update with everyone..

    With some help from Rayson we're down to the last parts

    1) Fix segfault with ipa (I suspect FreeBSD/OpenSolaris)
    2) Minor linker change (Sun ld only)
    3) CPUID for platforms without /proc/cpuinfo (FreeBSD/OpenSolaris)
    4) Makefile clean-up

    Anyone who wants to help can email me and I'll set them up with ssh access.
    -----------------

    Here's the patch against current svn.
    http://pkg.osunix.org/open64/open64-opensolaris-fbsd-merged-3-12.diff.gz

    ------------------

    Currently adding -ipa will dump core

    /usr/local/src/bar/open64/usr/lib/ipl -PHASE:p:i -O2 -show -TARG:abi=n32
    -LANG:cxx_openmp=on -LANG:=ansi_c -fB,hello.B -fo,hello.o hello.c -cmds
    opencc -show -TARG:abi=n32 -TARG:processor=anyx86 -TARG:sse2=off
    -TARG:mmx=off -TARG:sse=off -TARG:sse3=off -TARG:3dnow=off -TARG:sse4a=off

    core file:
    http://pkg.osunix.org/open64/error-core


    Stack:
    where
    [1] kill(0x5e09, 0x4, 0xffffff022a6360c0, 0xffffdd7fff5037aa, 0x50, 0xfb0),
    at 0xffffdd7fff50389a
    =>[2] ErrMsg_Report_User(edesc = 0x42d7f0, ecode = 1010, line = 0, file =
    (nil), vp = 0xfffffd7fffdfed00), line 1148 in "errors.cxx"
    [3] ErrMsg_Report(ecode = 1010, line = 0, file = (nil), vp =
    0xfffffd7fffdfed00), line 1175 in "errors.cxx"
    [4] ErrMsgLine(ecode = 1010, line = 0, ...), line 1221 in "errors.cxx"
    [5] catch_signal(sig = 11, error_num = 0), line 305 in "errors.cxx"
    [6] __sighndlr(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffdd7fff4fae46
    [7] call_user_handler(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffdd7fff4ee00f
    [8] sigacthandler(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffdd7fff4ee21e
    ---- called from signal handler with signal 11 (SIGSEGV) ------
    [9] 0x0(0xb, 0x439220, 0x0, 0x1, 0x0, 0xffffdd7fffdfb650), at 0x0
    [10] load_components(argc = 21, argv = 0xfffffd7fffdff3a8), line 509 in
    "driver.cxx"
    [11] main(argc = 21, argv = 0xfffffd7fffdff3a8), line 2244 in "driver.cxx"
    ---------
    Linker should pass -R instead of -rpath-link

    /opt/gcc/gcc-4.1/libexec/gcc/i386-pc-solaris2.11/4.1.2/collect2 -V -Y
    P,/usr/ccs/lib:/usr/lib -Qy /usr/lib/crt1.o /usr/lib/crti.o
    /usr/lib/values-Xa.o
    /opt/gcc/gcc-4.1/lib/gcc/i386-pc-solaris2.11/4.1.2/crtbegin.o
    -L/usr/local/src/bar/open64//usr/lib/32
    -L/opt/gcc/gcc-4.1/lib/gcc/i386-pc-solaris2.11/4.1.2
    -L/opt/gcc/gcc-4.1/lib/gcc/i386-pc-solaris2.11/4.1.2/../../.. -rpath-link
    /usr/local/src/bar/open64//usr/lib/32 hello.o -lgcc -lgcc_eh -lc -lgcc
    -lgcc_eh /opt/gcc/gcc-4.1/lib/gcc/i386-pc-solaris2.11/4.1.2/crtend.o
    /usr/lib/crtn.o
    ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1641
    ld: elf error: file /usr/local/src/bar/open64//usr/lib/32: elf_begin: I/O
    error: region read: Is a directory
    ld: fatal: file processing errors. No output written to a.out
    collect2: ld returned 1 exit status


    With that change the hello world will link and run..

    Hope I haven't made too much noise..


    Thanks

    ./Christopher

    ----

    Community driven OpenSolaris Technology - http://www.osunix.org
    blog: http://www.codestrom.com
  • Christopher Bergström at Mar 3, 2009 at 7:45 am

    John Martin wrote:
    C. Bergstr?m wrote:

    1) Best way to replace /proc/cpuinfo for OpenSolaris?

    opencc -v
    opencc WARNING: cannot read /proc/cpuinfo, defaulting to basic 32-bit
    x86.
    This code is looking for the plain text processor description, e.g.
    "Intel(R) Core(TM) i7". On Solaris this can be fetched with smbios.
    I don't know the stability of the interfaces in libsmbios.so.1. I can
    investigate this later this week.
    If you would be so kind I think that may be the cleanest solution..
    Otherwise, I see two quick choices.

    1) http://svn.mplayerhq.hu/mplayer/trunk/cpuinfo.c?view=markup

    2) parse the output from psrinfo and isainfo

    The problems
    #1 we'll have to sync it from upstream
    #2 the compiler then depends on those to be present..


    Thanks

    ./C

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouposunix-dev @
categoriesopensolaris
postedMar 2, '09 at 11:31p
activeMar 16, '09 at 11:36p
posts16
users4
websiteopensolaris.org

People

Translate

site design / logo © 2017 Grokbase