Add support for amd64 target

Add support for amd64 target

[Michael McConville]

AMD64 and x86-64 are effectively interchangeable terms. BSDs use the
prior while Linux uses the latter. The below patch therefore fixes
configure on OpenBSD.

For what it's worth, the build then survives until linking. I haven't
had a chance to diagnose that problem yet.

Thanks for your time,
Michael


diff --git a/configure b/configure
index 213a825..e961800 100755
--- a/configure
+++ b/configure
@@ -306,7 +306,7 @@ i?86-nt32*) ARCH=nt32 ;;
 i?86*) ARCH=i386 ;;
 x86_64-x32*|x32*|x86_64*x32) ARCH=x32 ;;
 x86_64-nt64*) ARCH=nt64 ;;
-x86_64*) ARCH=x86_64 ;;
+x86_64*|amd64*) ARCH=x86_64 ;;
 mips64*) ARCH=mips64 ;;
 mips*) ARCH=mips ;;
 microblaze*) ARCH=microblaze ;;

Re: Add support for amd64 target

[Rich Felker]

On Thu, Mar 17, 2016 at 10:33:41PM -0400, Michael McConville wrote:
> AMD64 and x86-64 are effectively interchangeable terms. BSDs use the
> prior while Linux uses the latter. The below patch therefore fixes
> configure on OpenBSD.

I'm not opposed to adding this if you think it will help, but I'm
skeptical of whether a toolchain targeting OpenBSD can produce a
working musl build anyway. Are you trying to get something that runs
on OpenBSD or use the OpenBSD compiler as a makeshift cross compiler
to get a normal Linux build?

> For what it's worth, the build then survives until linking. I haven't
> had a chance to diagnose that problem yet.

What are the linker errors you hit? It's not surprising that compiling
would work since no files external to the musl source tree are
accessed during compiling, but linking could bring in lots of issues,
and runtime even more.

Rich

Re: Add support for amd64 target

[Michael McConville]

Rich Felker wrote:
> On Thu, Mar 17, 2016 at 10:33:41PM -0400, Michael McConville wrote:
> > AMD64 and x86-64 are effectively interchangeable terms. BSDs use the
> > prior while Linux uses the latter. The below patch therefore fixes
> > configure on OpenBSD.
> 
> I'm not opposed to adding this if you think it will help, but I'm
> skeptical of whether a toolchain targeting OpenBSD can produce a
> working musl build anyway. Are you trying to get something that runs
> on OpenBSD or use the OpenBSD compiler as a makeshift cross compiler
> to get a normal Linux build?

FreeBSD and RISC-V (one an OS and the other an architecture, of course)
both have Google Summer of Code projects for porting musl. This
interests me, and because I'm on OpenBSD developer I thought I'd give it
a try on OpenBSD.

Whether or not I do either of the GSoC projects or follow through with
an OpenBSD port, it's likely that someone will take up the FreeBSD
project. In that case, this patch will have to be applied.

I'm hopeful that BSD ports won't be invasive, considering how long the
unpatched (ignoring the trivial configure patch) build ran.

> > For what it's worth, the build then survives until linking. I haven't
> > had a chance to diagnose that problem yet.
> 
> What are the linker errors you hit? It's not surprising that compiling
> would work since no files external to the musl source tree are
> accessed during compiling, but linking could bring in lots of issues,
> and runtime even more.

On what seems to be the final link command (judged from the number of
object files involved), I get this:

> obj/src/aio/aio.lo: In function `aio_cancel64':
> aio.c:(.text.aio_cancel+0x19): undefined reference to `__guard_local'
> /usr/bin/ld: obj/src/aio/aio.lo: relocation R_X86_64_PC32 against `__guard_local' can not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status
> Makefile:163: recipe for target 'lib/libc.so' failed
> gmake: *** [lib/libc.so] Error 1

We have some unique PIE features on by default, so this doesn't surprise
me.

I can share a full build log if you're interested.

Re: Add support for amd64 target

[Michael McConville]

Rich Felker wrote:
> On Thu, Mar 17, 2016 at 10:33:41PM -0400, Michael McConville wrote:
> > For what it's worth, the build then survives until linking. I
> > haven't had a chance to diagnose that problem yet.
> 
> What are the linker errors you hit? It's not surprising that compiling
> would work since no files external to the musl source tree are
> accessed during compiling, but linking could bring in lots of issues,
> and runtime even more.

To clarify: I thought the platform-specific bits would cause more
problems at runtime than at compile-time, but the more I think about
that the less it makes sense. You're definitely right - getting a
reliably working port will take a good deal of work (hence it being
offered as a three-month project). It's just nice to know that the
actual C code is reasonably portable.

Re: Add support for amd64 target

[Isaac Dunham]

On Thu, Mar 17, 2016 at 11:54:47PM -0400, Michael McConville wrote:
> Rich Felker wrote:
> > On Thu, Mar 17, 2016 at 10:33:41PM -0400, Michael McConville wrote:
> > > AMD64 and x86-64 are effectively interchangeable terms. BSDs use the
> > > prior while Linux uses the latter. The below patch therefore fixes
> > > configure on OpenBSD.
> > 
> > I'm not opposed to adding this if you think it will help, but I'm
> > skeptical of whether a toolchain targeting OpenBSD can produce a
> > working musl build anyway. Are you trying to get something that runs
> > on OpenBSD or use the OpenBSD compiler as a makeshift cross compiler
> > to get a normal Linux build?
> 
> FreeBSD and RISC-V (one an OS and the other an architecture, of course)
> both have Google Summer of Code projects for porting musl. This
> interests me, and because I'm on OpenBSD developer I thought I'd give it
> a try on OpenBSD.
> 
> Whether or not I do either of the GSoC projects or follow through with
> an OpenBSD port, it's likely that someone will take up the FreeBSD
> project. In that case, this patch will have to be applied.
> 
> I'm hopeful that BSD ports won't be invasive, considering how long the
> unpatched (ignoring the trivial configure patch) build ran.
> 
> > > For what it's worth, the build then survives until linking. I haven't
> > > had a chance to diagnose that problem yet.
> > 
> > What are the linker errors you hit? It's not surprising that compiling
> > would work since no files external to the musl source tree are
> > accessed during compiling, but linking could bring in lots of issues,
> > and runtime even more.
> 
> On what seems to be the final link command (judged from the number of
> object files involved), I get this:
> 
> > obj/src/aio/aio.lo: In function `aio_cancel64':
> > aio.c:(.text.aio_cancel+0x19): undefined reference to `__guard_local'
> > /usr/bin/ld: obj/src/aio/aio.lo: relocation R_X86_64_PC32 against `__guard_local' can not be used when making a shared object; recompile with -fPIC
> > /usr/bin/ld: final link failed: Bad value
> > collect2: ld returned 1 exit status
> > Makefile:163: recipe for target 'lib/libc.so' failed
> > gmake: *** [lib/libc.so] Error 1
> 
> We have some unique PIE features on by default, so this doesn't surprise
> me.

This means that you've got OpenBSD SSP turned on.
It's no surprise that this doesn't work; for an overview of some trouble
spots, I'll mention this link:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20130603/176378.html
Try turning it off (-fno-stack-protector or equivalent) for starters.
Long-term, a proper port might require patching musl to support OpenBSD
SSP.

By the way, is this the stock OpenBSD GCC 4.2?


HTH,
Isaac Dunham

Re: Add support for amd64 target

[Michael McConville]

Isaac Dunham wrote:
> > On what seems to be the final link command (judged from the number of
> > object files involved), I get this:
> > 
> > > obj/src/aio/aio.lo: In function `aio_cancel64':
> > > aio.c:(.text.aio_cancel+0x19): undefined reference to `__guard_local'
> > > /usr/bin/ld: obj/src/aio/aio.lo: relocation R_X86_64_PC32 against `__guard_local' can not be used when making a shared object; recompile with -fPIC
> > > /usr/bin/ld: final link failed: Bad value
> > > collect2: ld returned 1 exit status
> > > Makefile:163: recipe for target 'lib/libc.so' failed
> > > gmake: *** [lib/libc.so] Error 1
> > 
> > We have some unique PIE features on by default, so this doesn't surprise
> > me.
> 
> This means that you've got OpenBSD SSP turned on.
> 
> It's no surprise that this doesn't work; for an overview of some trouble
> spots, I'll mention this link:
> 
> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20130603/176378.html
> 
> Try turning it off (-fno-stack-protector or equivalent) for starters.
> Long-term, a proper port might require patching musl to support OpenBSD
> SSP.

Thanks for the input! The LLVM mail is very useful.

musl links and completes the build successfully with
-fno-stack-protector. I was hesitant to even try that because (IIUC) a
libc port with the stack protector disabled definitely wouldn't fly. A
cursory grep suggests that we only build four ports with
-fno-stack-protector.

> By the way, is this the stock OpenBSD GCC 4.2?

It is. For ports, we use it whenever possible, switching to the Clang or
GCC 4.9 port when something build no longer works with the base
compiler.