Re: Miscellaneous questions
Den 03/05/2013 kl. 03.08 skrev Kennith Caudill k...@furosys.com: 2.) Alternative linkers Is there a document available detailing the current feasible linkers and their status? Not that I'm aware of. mclinker is work in progress and is not yet able to link the kernel. gold should work, but I'm not aware that LTO linking has been tested to work. Apart from this, we need a general solution to having multiple linkers installed and choosing which one to use in general, during buildworld, for ports etc. Erik ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
[patch] crunchide breaks object files when using mclinker to do base system linking
Hello list,
On behalf of Pete Chou, I would like to ask for review, testing and hopefully
commit help of this revised patch for crunchgen and crunchide which allows
mclinker (http://code.google.com/p/mclinker/) to link the base system. In
short, this patch is needed because crunchide is being overly strict about the
section layout of an object file.
Thanks,
Erik
Index: exec_elf32.c
===
--- exec_elf32.c(revision 244199)
+++ exec_elf32.c(working copy)
@@ -45,6 +45,7 @@
#include sys/stat.h
#include errno.h
+#include limits.h
#include stdio.h
#include stdlib.h
#include string.h
@@ -82,11 +83,9 @@
#definexe32toh(x) ((data == ELFDATA2MSB) ? be32toh(x) :
le32toh(x))
#definehtoxe32(x) ((data == ELFDATA2MSB) ? htobe32(x) :
htole32(x))
-struct listelem {
- struct listelem *next;
- void *mem;
- off_t file;
- size_t size;
+struct shlayout {
+ Elf_Shdr *shdr;
+ void *bufp;
};
static ssize_t
@@ -235,17 +234,20 @@
ELFNAMEEND(hide)(int fd, const char *fn)
{
Elf_Ehdr ehdr;
- Elf_Shdr *shdrp = NULL, *symtabshdr, *strtabshdr;
+ struct shlayout *layoutp = NULL;
+ Elf_Shdr *shdrp = NULL, *symtabshdr, *strtabshdr, *shstrtabshdr;
+ Elf_Shdr shdrshdr;
Elf_Sym *symtabp = NULL;
- char *strtabp = NULL;
- Elf_Size nsyms, ewi;
+ char *shstrtabp = NULL, *strtabp = NULL;
+ Elf_Size nsyms, ewi;
+ Elf_Off off;
ssize_t shdrsize;
- int rv, i, weird;
- size_t nstrtab_size, nstrtab_nextoff, fn_size;
+ int rv, i, weird, l, m, r, strtabidx;
+ size_t nstrtab_size, nstrtab_nextoff, fn_size, size;
char *nstrtabp = NULL;
unsigned char data;
- Elf_Off maxoff, stroff;
const char *weirdreason = NULL;
+ void *buf;
rv = 0;
if (xreadatoff(fd, ehdr, 0, sizeof ehdr, fn) != sizeof ehdr)
@@ -260,63 +262,124 @@
shdrsize)
goto bad;
- symtabshdr = strtabshdr = NULL;
+ symtabshdr = strtabshdr = shstrtabshdr = NULL;
weird = 0;
- maxoff = stroff = 0;
for (i = 0; i xe16toh(ehdr.e_shnum); i++) {
- if (xewtoh(shdrp[i].sh_offset) maxoff)
- maxoff = xewtoh(shdrp[i].sh_offset);
switch (xe32toh(shdrp[i].sh_type)) {
case SHT_SYMTAB:
- if (symtabshdr != NULL)
+ if (symtabshdr != NULL) {
weird = 1;
+ weirdreason = multiple symbol tables;
+ }
symtabshdr = shdrp[i];
strtabshdr = shdrp[xe32toh(shdrp[i].sh_link)];
-
- /* Check whether the string table is the last section */
- stroff =
xewtoh(shdrp[xe32toh(shdrp[i].sh_link)].sh_offset);
- if (!weird xe32toh(shdrp[i].sh_link) !=
(xe16toh(ehdr.e_shnum) - 1)) {
- weird = 1;
- weirdreason = string table not last section;
- }
break;
+ case SHT_STRTAB:
+ if (i == xe16toh(ehdr.e_shstrndx))
+ shstrtabshdr = shdrp[i];
+ break;
}
}
- if (! weirdreason)
- weirdreason = unsupported;
if (symtabshdr == NULL)
goto out;
- if (strtabshdr == NULL)
+ if (strtabshdr == NULL) {
weird = 1;
- if (!weird stroff != maxoff) {
+ weirdreason = string table does not exist;
+ }
+ if (shstrtabshdr == NULL) {
weird = 1;
- weirdreason = string table section not last in file;
- }
+ weirdreason = section header string table does not exist;
+ }
+ if (weirdreason == NULL)
+ weirdreason = unsupported;
if (weird) {
fprintf(stderr, %s: weird executable (%s)\n, fn, weirdreason);
goto bad;
}
/*
+* sort section layout table by offset
+*/
+ layoutp = xmalloc(sizeof(struct shlayout) * (xe16toh(ehdr.e_shnum) + 1),
+ fn, layout table);
+ if (layoutp == NULL)
+ goto bad;
+
+ /* add a pseudo entry to represent the section header table */
+ shdrshdr.sh_offset = ehdr.e_shoff;
+ shdrshdr.sh_size = htoxew(shdrsize);
+ shdrshdr.sh_addralign = htoxew(ELFSIZE / 8);
+ layoutp[xe16toh(ehdr.e_shnum)].shdr = shdrshdr;
+
+ /* insert and sort normal section headers */
+ for (i = xe16toh(ehdr.e_shnum) - 1; i = 0; i--) {
+ l = i + 1;
+ r = xe16toh(ehdr.e_shnum);
+ while (l = r) {
+ m = ( l + r)
Re: Using non-standard linker
Hello Warner, Den 13/12/2012 kl. 15.48 skrev Warner Losh i...@bsdimp.com: Install ld as ld.gnu during the build and after. Make ld a small shell script that invokes ld.gnu by default, or something else if a variable is set. Much like the way we have different mail backends to a common mail front end. Then ld does what people want, and you have a hook to do different things. Thanks for the suggestion. Would this be acceptable in FreeBSD if I created a patch, or are you just suggesting it for my local testing? Thanks, Erik ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Using non-standard linker
Hi folks, I'm working with Pete Chou from MCLinker (actually, he's doing almost all the work) to get mclinker to survive a buildworld. The goal is to allow mclinker to be a drop-in replacement for GNU ld. My first suggestion was to just add LD=/usr/local/bin/mclinker to src.conf. But this only works when ld is invoked explicitly (and only when 'ld' is not hard-coded, of course). When ld is invoked internally by the compiler, Pete has tested that gcc(collect2) and clang do not respect the LD variable, but search for 'ld' in COMPILER_PATH and then PATH instead. Since mclinker is not part of the build process, it isn't found in COMPILER_PATH, and GNU ld is used instead. Instead, he can add an additional compiler search path via the -B flag, which seems to work. I'm worried that 'ld' is so hard-wired everywhere that it's impossible to specify another name. In that case, my suggestion would be to use build knobs, e.g. WITH_GNU_LD and WITH_MCLINKER_LD to install either GNU ld or mclinker as 'ld', but that wouldn't work unless mclinker is imported into base. What's the FreeBSD way of doing this? What do other toolchains do if they use a non-GNU ld linker? Thanks, Erik ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: crunchide breaks object files when using mclinker to do base system linking
Den 27/11/2012 kl. 09.00 skrev pete petec...@gmail.com: Hi, I meet a problem when using mclinker to do base system linking. And the problem is crunchide is gnu ld specific. it presumes the section layout of a object file is like what gnu ld generates. To make it clear, gnu ld would generate the following layout. And crunchide will update elf section header, symbol table, and then string table. (The string table is likely enlarged.) ld -dc -r -o cat.lo cat_stub.o /usr/obj/usr/src/rescue/rescue//usr/src/bin/cat/cat.o crunchide -k _crunched_cat_stub cat.lo gnu ld + elf header + -- ++ ++ -- + elf section header + -- + symbol table + -- + string table + -- However, mclinker does not produce this layout, but put elf section header in the end of file. And then crunchide will break the object file generated by mclinker. (elf section header is overwritten by new strings) I know the layout generated by gold linker is also different to gnu ld. On the other hand, we can find only ELF header is required to be fixed in *System V Application Binary Interface*. For mclinker, I think it's not difficult to add the change to be compatible with gnu ld. But do you think if it will be better to modify crunchide utility to support more elf linkers? Unless you have compelling technical reasons to keep your layout, I think it's better for mclinker to be as compatible with GNU ld as possible, even though your layout also adheres to the standards. If other tools in FreeBSD or other platforms also make assumptions about the header layout, you'll end up patching lots of tools instead of working on mclinker. With that in mind, I also think it's worthwhile to patch our crunchide to be more permissive. If you have the resources, please send patches. Thanks, Erik ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
Den 12/09/2012 kl. 11.29 skrev Doug Barton do...@freebsd.org: On 09/11/2012 02:52 AM, Erik Cederstrand wrote: So can we do a sweep on the ports tree and mark the 2232 ports with USE_GCC=4.2 until they can actually build with clang? Unfortunately it isn't that simple. We already have a statistically significant number of ports that don't even compile with gcc 4.2.1. How many compilers do we expect the users to install? :) If a port doesn't compile with the default compiler in base, I expect that port to add a build dependency on the compiler that it actually does compiles with. Of course, I hope to not have 6 different compilers installed on my system, but the list of build or runtime dependencies are at the discretion of the port (maintainer). As you (I think) said, we can't force port maintainers to patch their ports to support clang. So even today, we have a significant number of ports that don't compile with the default compiler (GCC 4.2.1). Aren't they broken already, in the sense that they fail to tell me, the user, which compiler I should use? Thanks, Erik___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
Roman, Den 11/09/2012 kl. 14.38 skrev Roman Divacky rdiva...@freebsd.org: Upstream developers almost never use gcc4.2.1 as we do. So right now the ports maintainer must check whats wrong in the case the (upgraded) port doesnt compile with our in-tree gcc. It can be trivial USE_GCC=4.something but the burden is exactly the same as with clang. So can we do a sweep on the ports tree and mark the 2232 ports with USE_GCC=4.2 until they can actually build with clang? This could allow the clang switch to proceed. Hopefully, waiting for GCC to compile just to install some tiny port will be enough of a nuisance for people to eventually fix the remaining ports. By the nature of developing the OS we are forced to use compilers and toolchains. Recently I saw you submitting/committing patches with .byte sequences because our default assembler cant handle the instructions. I saw jhb@ updating binutils to support invept/invvpid. In my eyes, switching to clang by default lowers the compiler/toolchain maintenance burden we have. I agree. Switching away from abandonware to a compiler that is actively maintained is a good thing. Regarding performance, I could do some benchmarking in my spare time, but it does seem like an unforgiving task. Anyone posting any benchmark numbers on these lists is going to be tarred, feathered, forced to print out the full GCC 4.2.1 source code, read it out loud on the town square, and spend the next month addressing concerns from people not willing to do the work themselves :-) Erik___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: BSD ld (was Re: MCLinker and llvm-config)
Den 28/07/2012 kl. 16.15 skrev Pedro Giffuni: Hello; The Elftoolchain project has been developing a BSD ld: http://sourceforge.net/apps/trac/elftoolchain/ http://sourceforge.net/apps/trac/elftoolchain/browser/trunk/ld I thought that would be the official FreeBSD implementation. I asked about progress recently on ELFToolchain ld, but it currently only handles simple programs: http://sourceforge.net/mailarchive/message.php?msg_id=29593381 LLVM ld is in its very early stages of development. (http://lld.llvm.org) gold is GPLv3. MCLinker seems to me like the most promising project at the moment. But in the end, working code is what counts :-) Erik___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
MCLinker and llvm-config
Hi list, I'm creating a FreeBSD port for MCLinker (http://code.google.com/p/mclinker/) in preparation of MCLinker working without patching LLVM, and testing MCLinker as a system linker when it gets far enough. In the configure stage, MCLinker needs to run llvm-config, which is not installed by default in FreeBSD, even when WITH_CLANG_EXTRAS is set. What is the best option to get llvm-config on my system? Can I just run make make install somewhere in /usr/src? Thanks, Erik Cederstrand___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
[patch] Add -iremap src:dst option to gcc
Hi folks,
I found this patch by Joerg Sonnenberger to NetBSD's gcc which adds an -iremap
src:dst option to gcc
(http://www.mail-archive.com/source-changes-full@netbsd.org/msg08590.html).
The option rewrites the prefix to __FILE__ which is stored in the object file.
My use-case is to make __FILE__ a relative path instead of an absolute one,
e.g. src/foo/bar.c instead of /home/erik/freebsd/gcc_iremap/src/foo/bar.c.
This is one of the requisites to create identical binaries from source code in
different locations on my system.
The option can be used in e.g. make.conf as:
CFLAGS += -iunwrap=${.IMPSRC}:src
Patch against HEAD is attached. Is anyone willing to review this and possibly
commit?
Thanks,
Erik
iremap.diff
Description: Binary data
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: [RFC] Un-staticise the toolchain
Den 26/04/2012 kl. 11.35 skrev Konstantin Belousov: I think it is time to stop building the toolchain static. I was told that original reasoning for static linking was the fear of loosing the ability to recompile if some problem appears with rtld and any required dynamic library. Apparently, current dependencies are much more spread, e.g. /bin/sh is dynamically linked, and statically linked make does not solve anything. What are the benefits, apart from using a bit less disk space overall? Apparently, toolchain bits aren't considered important enough to be included in /rescue. Maybe they need to be, if the assumption currently is that the compiler will (almost) always work. Erik___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: -integrated-as status?
Den 17/12/2010 kl. 15.02 skrev Roman Divacky: On Fri, Dec 17, 2010 at 02:58:34PM +0100, Erik Cederstrand wrote: Hello toolchainers, It is my understanding that -integrated-as is supposed to work for ELF on FreeBSD now. Is anybody working on supporting this flag for buildworld/kernel? -integrated-as works quite well for compiler produces .s files, it has some problems with human written .s/.S files. bottom line - it cant compile kernel right now but we are working on it Cool, thanks! Erik
