FAQ
Any guesses about the 386 build breakages?
I can't reproduce the darwin one locally. I suspect ld/decodesym.c is
not quite right for 32-bit (I don't think dwarf gets used for windows or
arm) but I cannot reproduce it, nor can I see the problem.

It is possible that the StructType and its fields are not always
contiguous in memory, and that decodetype_structfieldname and
decodetype_structfieldtype need to load the pointer from the slice
header and then walk from there.

http://codereview.appspot.com/6281048/

Search Discussions

  • 0xe2 0x9a 0x9b at Sep 14, 2012 at 11:19 am

    On 2012/09/14 03:08:47, rsc wrote:
    Any guesses about the 386 build breakages?
    I can't reproduce the darwin one locally. I suspect ld/decodesym.c is not quite
    right for 32-bit (I don't think dwarf gets used for windows or arm)
    but I cannot
    reproduce it, nor can I see the problem.
    I am unable to reproduce the issue on my linux/386 machine.

    https://codereview.appspot.com/6281048/
  • Dave Cheney at Sep 14, 2012 at 11:59 am
    I can reproduce the problem on ubuntu 12.04.1, gcc 4.6.3, ld 2.22. This is
    an amd64 host cross compiling with GOARCH=386.
    On Fri, Sep 14, 2012 at 9:19 PM, wrote:
    On 2012/09/14 03:08:47, rsc wrote:

    Any guesses about the 386 build breakages?
    I can't reproduce the darwin one locally. I suspect ld/decodesym.c is not quite
    right for 32-bit (I don't think dwarf gets used for windows or arm)
    but I cannot
    reproduce it, nor can I see the problem.
    I am unable to reproduce the issue on my linux/386 machine.

    https://codereview.appspot.**com/6281048/<https://codereview.appspot.com/6281048/>
  • Russ Cox at Sep 14, 2012 at 12:25 pm
    Aha.

    Usually when I build for 386 on my 64-bit machine I use GOARCH=386
    GOHOSTARCH=386. But if you only do GOARCH=386 (GOHOSTARCH=amd64 by
    default) then you get the failure.

    Russ
  • Dave Cheney at Sep 14, 2012 at 1:01 pm
    I believe this is how the builders build, ie, they do not set GOHOST*
    On Fri, Sep 14, 2012 at 10:20 PM, Russ Cox wrote:

    Aha.

    Usually when I build for 386 on my 64-bit machine I use GOARCH=386
    GOHOSTARCH=386. But if you only do GOARCH=386 (GOHOSTARCH=amd64 by
    default) then you get the failure.

    Russ
  • 0xe2 0x9a 0x9b at Sep 15, 2012 at 8:06 am

    On 2012/09/14 12:20:27, rsc wrote:
    Aha.
    Usually when I build for 386 on my 64-bit machine I use GOARCH=386
    GOHOSTARCH=386. But if you only do GOARCH=386 (GOHOSTARCH=amd64 by
    default) then you get the failure.
    Russ
    Fix: https://codereview.appspot.com/6493123/

    https://codereview.appspot.com/6281048/
  • Russ Cox at Sep 17, 2012 at 8:44 pm
    Thanks!
  • Minux at Sep 20, 2012 at 5:33 pm
    Hi,

    With this change, Linux/arm binaries are much bigger (size doubled at
    least).
    For example, .gcbss section of go_bootstrap alone is 8MiB.
    Is this expected?

    FYI, you can just do this on linux to verify the problem without an arm
    machine:
    GOARCH=arm GOHOSTARCH=arm ./make.bash
    ignore the build error and look at the size of go_bootstrap.
  • ⚛ at Sep 20, 2012 at 6:28 pm

    On Thu, Sep 20, 2012 at 7:33 PM, minux wrote:
    Hi,

    With this change, Linux/arm binaries are much bigger (size doubled at
    least).
    For example, .gcbss section of go_bootstrap alone is 8MiB.
    Is this expected?

    FYI, you can just do this on linux to verify the problem without an arm
    machine:
    GOARCH=arm GOHOSTARCH=arm ./make.bash
    ignore the build error and look at the size of go_bootstrap.
    The cause of the problem is that .bss section on ARM is substantially
    larger than .bss on 386 (see the two attached files). Most of the data
    in ARM's .bss section should be in .noptrbss section, like on 386.
  • Minux at Sep 21, 2012 at 5:39 am

    On Friday, September 21, 2012, ⚛ wrote:
    The cause of the problem is that .bss section on ARM is substantially
    larger than .bss on 386 (see the two attached files). Most of the data
    in ARM's .bss section should be in .noptrbss section, like on 386.
    Yeah, somehow runtime.mheap is placed in .bss instead of .noptrbss,
    could be a regression. I will investigate it.

    BTW, 8 MiB of GC data for a ~4MiB struct seems not very memory
    efficient. Is this expected?
  • 0xe2 0x9a 0x9b at Sep 21, 2012 at 6:19 am

    On 2012/09/21 05:39:05, minux wrote:
    BTW, 8 MiB of GC data for a ~4MiB struct seems not very memory
    efficient. Is this expected?
    One reason why the GC data consumed so much space is that all integers
    (even small ones) need to be aligned to a word boundary because of
    performance reasons.

    It is possible that the encoding can be made more space efficient. I am
    now trying to split CL 6114046 into smaller parts and send those parts
    for inclusion in Go. I have decided not to attempt any further
    optimizations until the whole CL 6114046 is submitted. My 4 month old
    comment in https://codereview.appspot.com/6114046/#msg16 says that
    "There will be no changes to this patch set, ..." - I am strictly
    holding to this rule even if it partially seems irrational to do so.

    https://codereview.appspot.com/6281048/
  • Minux at Sep 21, 2012 at 7:15 am

    On Fri, Sep 21, 2012 at 2:19 PM, wrote:
    On 2012/09/21 05:39:05, minux wrote:

    BTW, 8 MiB of GC data for a ~4MiB struct seems not very memory
    efficient. Is this expected?
    One reason why the GC data consumed so much space is that all integers
    (even small ones) need to be aligned to a word boundary because of
    performance reasons. i see.
    It is possible that the encoding can be made more space efficient.
    hope you have plan for this :)
    because i have a project where memory is a very scarce resource so
    i'd really like to use your precise GC enhancements.

    thank you for your wonderful work.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedSep 14, '12 at 3:08a
activeSep 21, '12 at 7:15a
posts12
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase