[9fans] Go tip build fails

[Skip Tavakkolian]

Go build is failing today and no mention of it in issue tracker. Anyone
else seeing this problem?

...
cmd/go
main.parseMetaGoImports: pc-relative relocation address is too big:
0x10003b677
main.parseMetaGoImports: pc-relative relocation address is too big:
0x100040cf3
main.parseMetaGoImports: pc-relative relocation address is too big:
0x100049702
main.init·1: pc-relative relocation address is too big: 0x10003b61a
main.init·1: pc-relative relocation address is too big: 0x100000325
main.init·1: pc-relative relocation address is too big: 0x100000317
main.buildCompiler.Set: pc-relative relocation address is too big:
0x10003b5c7
main.buildCompiler.Set: pc-relative relocation address is too big:
0x1000555a2
main.buildCompiler.Set: pc-relative relocation address is too big:
0x100040b62
main.buildCompiler.Set: pc-relative relocation address is too big:
0x100055508
main.buildCompiler.Set: pc-relative relocation address is too big:
0x100040ad0
main.buildCompiler.Set: pc-relative relocation address is too big:
0x100040b13
main.buildCompiler.Set: pc-relative relocation address is too big:
0x10005f1ed
main.buildCompiler.String: pc-relative relocation address is too big:
0x10003b3f7
main.init·2: pc-relative relocation address is too big: 0x10003b3ca
main.init·2: pc-relative relocation address is too big: 0x1000553a5
main.init·2: pc-relative relocation address is too big: 0x100040965
main.init·2: pc-relative relocation address is too big: 0x10005532f
main.init·2: pc-relative relocation address is too big: 0x1000408f7
main.addBuildFlags: pc-relative relocation address is too big: 0x10003b2b7
main.addBuildFlags: pc-relative relocation address is too big: 0x10005a7fb
too many errors

[Rob Pike]

Are you using Plan 9? Because I don't understand how you could get
those messages on Plan 9, but I do on other systems.

-rob

[Jacob Todd]

I'm experiencing the same problem.

[Skip Tavakkolian]

yes.

Post by Rob Pike
Are you using Plan 9? Because I don't understand how you could get
those messages on Plan 9, but I do on other systems.
-rob

[Rob Pike]

that means you are building from source

in the ld directory, look for assignments to rd->add from calls to e32. two do not do a cast to int32. try casting those two and let me know if you can

i will be at work in a couple of hours, not on a phone, and can offer more help then.


-rob

yes.

Post by Rob Pike
Are you using Plan 9? Because I don't understand how you could get
those messages on Plan 9, but I do on other systems.
-rob

[Skip Tavakkolian]

bootes% grep -n 'rp->add' *.[ch] | grep e32
ldelf.c:709: rp->add = e->e32(sect->base+rp->off);
ldmacho.c:807: rp->add = (int32)e->e32(s->p+rp->off) + rp->off + 4 -
secaddr;
ldmacho.c:809: rp->add = (int32)e->e32(s->p+rp->off);
ldpe.c:294: rp->add = (int32)le32(rsect->base+rp->off);
ldpe.c:300: rp->add = le32(rsect->base+rp->off);

it seems that ldelf.c:709 is the only place that fits your instructions.
doing the cast has no effect (i.e. fails building cmd/go with the same
error messages)

Post by Rob Pike
that means you are building from source
in the ld directory, look for assignments to rd->add from calls to e32.
two do not do a cast to int32. try casting those two and let me know if you
can
i will be at work in a couple of hours, not on a phone, and can offer more help then.
-rob
yes.

Post by Rob Pike
Are you using Plan 9? Because I don't understand how you could get
those messages on Plan 9, but I do on other systems.
-rob

[Skip Tavakkolian]

found the other instance at line ldelf.c:681; the assignment from e32 is
indirect via "add". same results as before.


On Wed, May 1, 2013 at 12:14 PM, Skip Tavakkolian <

Post by Skip Tavakkolian
bootes% grep -n 'rp->add' *.[ch] | grep e32
ldelf.c:709: rp->add = e->e32(sect->base+rp->off);
ldmacho.c:807: rp->add = (int32)e->e32(s->p+rp->off) + rp->off + 4 -
secaddr;
ldmacho.c:809: rp->add = (int32)e->e32(s->p+rp->off);
ldpe.c:294: rp->add = (int32)le32(rsect->base+rp->off);
ldpe.c:300: rp->add = le32(rsect->base+rp->off);
it seems that ldelf.c:709 is the only place that fits your instructions.
doing the cast has no effect (i.e. fails building cmd/go with the same
error messages)

Post by Rob Pike
that means you are building from source
in the ld directory, look for assignments to rd->add from calls to e32.
two do not do a cast to int32. try casting those two and let me know if you
can
i will be at work in a couple of hours, not on a phone, and can offer more help then.
-rob
yes.

Post by Rob Pike
Are you using Plan 9? Because I don't understand how you could get
those messages on Plan 9, but I do on other systems.
-rob

[Matthew Veety]

I don't think changing ldelf.c would fix this issue. IIRC we don't use it on Plan 9.

found the other instance at line ldelf.c:681; the assignment from e32 is indirect via "add". same results as before.

Post by Skip Tavakkolian
bootes% grep -n 'rp->add' *.[ch] | grep e32
ldelf.c:709: rp->add = e->e32(sect->base+rp->off);
ldmacho.c:807: rp->add = (int32)e->e32(s->p+rp->off) + rp->off + 4 - secaddr;
ldmacho.c:809: rp->add = (int32)e->e32(s->p+rp->off);
ldpe.c:294: rp->add = (int32)le32(rsect->base+rp->off);
ldpe.c:300: rp->add = le32(rsect->base+rp->off);
it seems that ldelf.c:709 is the only place that fits your instructions. doing the cast has no effect (i.e. fails building cmd/go with the same error messages)

Post by Rob Pike
that means you are building from source
in the ld directory, look for assignments to rd->add from calls to e32. two do not do a cast to int32. try casting those two and let me know if you can
i will be at work in a couple of hours, not on a phone, and can offer more help then.
-rob

yes.

Post by Rob Pike
Are you using Plan 9? Because I don't understand how you could get
those messages on Plan 9, but I do on other systems.
-rob

[Rob Pike]

The patch was not abandoned; that message was a codereview glitch.
It's checked in.

We need to find where the bogus relocation is coming from. It *is*
bogus, but the error catching it is new. To make progress, feel free
to comment out the code that prints the error. I'm pretty sure you'll
be fine. But I would like to understand where the bad relocation value
is coming from. It's caused by something like a -4 becoming
0xFFFFFFFC, which doesn't matter when everything's 32 bits but is
caught by the error checking code that's using 64 bits.

-rob

[Russ Cox]

Are you all using 386 or amd64 systems?

Russ

[Jacob Todd]

32 bit.

Post by Russ Cox
Are you all using 386 or amd64 systems?
Russ

[Skip Tavakkolian]

386 here.

Post by Russ Cox
Are you all using 386 or amd64 systems?
Russ

[Rob Pike]

It would be easier to debug this if there was a way I could log in to
a Plan 9 machine (or virtual machine) capable of compiling and running
the Go distribution. Such public services have existed in the past;
does one exist today? Please contact me privately if you can help.

-rob

[David du Colombier]

Post by Rob Pike
in the ld directory, look for assignments to rd->add from calls to
e32. two do not do a cast to int32. try casting those two and let me
know if you can

I made this change and it doesn't seem to fix the problem.

diff -r 3478ecc801f6 src/cmd/ld/ldelf.c
--- a/src/cmd/ld/ldelf.c Wed May 01 10:00:05 2013 -0400
+++ b/src/cmd/ld/ldelf.c Wed May 01 19:15:00 2013 +0000
@@ -706,7 +706,7 @@
else {
// load addend from image
if(rp->siz == 4)
- rp->add = e->e32(sect->base+rp->off);
+ rp->add = (int32)e->e32(sect->base+rp->off);
else if(rp->siz == 8)
rp->add = e->e64(sect->base+rp->off);
else
diff -r 3478ecc801f6 src/cmd/ld/ldpe.c
--- a/src/cmd/ld/ldpe.c Wed May 01 10:00:05 2013 -0400
+++ b/src/cmd/ld/ldpe.c Wed May 01 19:15:00 2013 +0000
@@ -297,7 +297,7 @@
case IMAGE_REL_I386_DIR32:
rp->type = D_ADDR;
// load addend from image
- rp->add = le32(rsect->base+rp->off);
+ rp->add = (int32)le32(rsect->base+rp->off);
break;
case IMAGE_REL_AMD64_ADDR64: // R_X86_64_64
rp->siz = 8;

[s***@9front.org]

troubleshooting

First

* STATE YOUR ASSUMPTIONS.

* cat /etc/os-release to verify you are not, in fact, running Ubuntu Linux with a
Plan 9 theme.

* Try the latest ISO image.

-sl

[David du Colombier]

Post by Skip Tavakkolian
Go build is failing today and no mention of it in issue tracker.
Anyone else seeing this problem?

Same problem here.

cmd/go
main.parseMetaGoImports: pc-relative relocation address is too big: 0x10003b677
main.parseMetaGoImports: pc-relative relocation address is too big: 0x100040cf3
main.parseMetaGoImports: pc-relative relocation address is too big: 0x100049702
main.init·1: pc-relative relocation address is too big: 0x10003b61a
main.init·1: pc-relative relocation address is too big: 0x100000325
main.init·1: pc-relative relocation address is too big: 0x100000317
main.buildCompiler.Set: pc-relative relocation address is too big: 0x10003b5c7
main.buildCompiler.Set: pc-relative relocation address is too big: 0x1000555a2
main.buildCompiler.Set: pc-relative relocation address is too big: 0x100040b62
main.buildCompiler.Set: pc-relative relocation address is too big: 0x100055508
main.buildCompiler.Set: pc-relative relocation address is too big: 0x100040ad0
main.buildCompiler.Set: pc-relative relocation address is too big: 0x100040b13
main.buildCompiler.Set: pc-relative relocation address is too big: 0x10005f1ed
main.buildCompiler.String: pc-relative relocation address is too big: 0x10003b3f7
main.init·2: pc-relative relocation address is too big: 0x10003b3ca
main.init·2: pc-relative relocation address is too big: 0x1000553a5
main.init·2: pc-relative relocation address is too big: 0x100040965
main.init·2: pc-relative relocation address is too big: 0x10005532f
main.init·2: pc-relative relocation address is too big: 0x1000408f7
main.addBuildFlags: pc-relative relocation address is too big: 0x10003b2b7
main.addBuildFlags: pc-relative relocation address is too big: 0x10005a7fb
too many errors

[Skip Tavakkolian]

the diagnostic string only appears in one place; it's in this presumably
abandoned patch:
https://codereview.appspot.com/9036046/

Post by David du Colombier

Post by Skip Tavakkolian
Go build is failing today and no mention of it in issue tracker.
Anyone else seeing this problem?

Same problem here.
cmd/go
main.parseMetaGoImports: pc-relative relocation address is too big: 0x10003b677
main.parseMetaGoImports: pc-relative relocation address is too big: 0x100040cf3
main.parseMetaGoImports: pc-relative relocation address is too big: 0x100049702
main.init·1: pc-relative relocation address is too big: 0x10003b61a
main.init·1: pc-relative relocation address is too big: 0x100000325
main.init·1: pc-relative relocation address is too big: 0x100000317
main.buildCompiler.Set: pc-relative relocation address is too big: 0x10003b5c7
main.buildCompiler.Set: pc-relative relocation address is too big: 0x1000555a2
main.buildCompiler.Set: pc-relative relocation address is too big: 0x100040b62
main.buildCompiler.Set: pc-relative relocation address is too big: 0x100055508
main.buildCompiler.Set: pc-relative relocation address is too big: 0x100040ad0
main.buildCompiler.Set: pc-relative relocation address is too big: 0x100040b13
main.buildCompiler.Set: pc-relative relocation address is too big: 0x10005f1ed
main.buildCompiler.String: pc-relative relocation address is too big: 0x10003b3f7
main.init·2: pc-relative relocation address is too big: 0x10003b3ca
main.init·2: pc-relative relocation address is too big: 0x1000553a5
main.init·2: pc-relative relocation address is too big: 0x100040965
main.init·2: pc-relative relocation address is too big: 0x10005532f
main.init·2: pc-relative relocation address is too big: 0x1000408f7
main.addBuildFlags: pc-relative relocation address is too big: 0x10003b2b7
main.addBuildFlags: pc-relative relocation address is too big: 0x10005a7fb
too many errors
--
David du Colombier

[Rob Pike]

Thanks to machines offered by Erik Quanstrom and David du Colombier, I
found the bug. Trivial fix is out for review.

C's "usual integer conversions" apply.

-rob