Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What the hell is a target triple?

mcyoung.xyz

Post reply on HN
Print view View original

101–110 of 139 posts

Re: What the hell is a target triple?

#101

Post by jcranmer »

IshKebab wrote: post #70
o11c wrote: post #63

Earlier quoted context omitted.

There are up to 7 components in a triple, but not all are used at once, the general format is: - - - But there's also , see below. Note that there are both canonical and non-canonical triples in use. Canonical triples are output by `config.guess` or `config.sub`; non-canonical triples are input to `config.sub` and used as prefixes for commands. The field (1st) is what you're running on, and on some systems it include…

Nah I dunno where you're getting your information from but LLVM only supports 5 components. See the code starting at line 1144 here: https://llvm.org/doxygen/Triple_8cpp_source.html The components are arch-vendor-os-environment-objectformat. It's absolutely full of special cases and hacks. Really at this point I think the only sane option is an explicit list of fixed strings. I think Rust does that.

You're not really contradicting o11c here; what LLVM calls "environment" is a mixture of what they called libc/abi/fabi. There's also what LLVM calls "subarch" to distinguish between different architectures that may be relevant (e.g., i386 is not the same as i686, although LLVM doesn't record this difference since it's generally less interested in targeting old hardware), and there's also OS version numbers that may or may not be relevant.

The underlying problem with target triples is that architecture-vendor-system isn't sufficient to uniquely describe the relevant details for specifying a toolchain, so the necessary extra information has been somewhat haphazardly added to the format. On top of that, since the relevance of some of the information is questionable for some tasks (especially the vendor field), different projects have chosen not to care about subtle differences, so the normalization of a triple is different between different projects.

LLVM's definition is not more or less correct than gcc's here, nor are these the only definitions floating around.

Re: What the hell is a target triple?

#102

Post by lonjil »

matheusmoreira wrote: post #34

> Go originally wanted to not have to link any system libraries, something that does not actually work It does work on Linux, the only kernel that promises a stable binary interface to user space. https://www.matheusmoreira.com/articles/linux-system-calls

FreeBSD does as well, but old ABI versions aren't kept forever.

Re: What the hell is a target triple?

#103

Post by o11c »

matheusmoreira wrote: post #91
eqvinox wrote: post #44

Earlier quoted context omitted.

Given TFA's bias against GCC, I'm not so sure. e.g. looking at the linker script article… it's also missing the __start_XYZ and __stop_XYZ symbols automatically created by the linker.

It also focuses exclusively on sections. I wish it had at least mentioned segments, also known as program headers. Linux kernel's ELF loader does not care about sections, it only cares about segments. Sections and segments are more or less the same concept: metadata that tells the loader how to map each part of the file into the correct memory regions with the correct memory protection attributes. Biggest difference…

I wouldn't call them "same concept" at all. Segments (program headers) are all about the runtime (executables and shared libraries) and are low-cost. Sections are all about development (.o files) and are detailed.

Generally there are many sections combined into a single segment, other than special-purpose ones. Unless you are reimplementing ld.so, you almost certainly don't want to touch segments; sections are far easier to work with.

Also, normally you just just call `getauxval`, but if needed the type is already named `ElfW(auxv_t)*`.

Re: What the hell is a target triple?

#105

Post by o11c »

debugnik wrote: post #86
cwood-sdf wrote: post #32

"And no, a “target quadruple” is not a thing and if I catch you saying that I’m gonna bonk you with an Intel optimization manual. " https://github.com/ziglang/zig/issues/20690

The argument is that they're called triples even when they've got more or less components than 3. They should have simply been called target tuples or target monikers.

"gnu tuple" and "gnu type" are also common names.

The comments in `config.guess` and `config.sub`, which are the origin of triples, use a large variety of terms, at least the following:

  configuration name
  configuration type
  [machine] specification
  system name
  triplet
  tuple

Re: What the hell is a target triple?

#106

Post by o11c »

fweimer wrote: post #4

I think GCC's more-or-less equivalent to Clang's --target is called -B: https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#in... I assume it works with an all-targets binutils build. I haven't seen anyone building their cross-compilers in this way (at least not in recent memory).

Old versions of GCC used to provide `-b ` (and also `-V `), but they were removed a long time ago in favor of expecting people to just use and set `CC` correctly.

It looks like gcc 3.3 through 4.5 just forwards to an external driver; prior to that it seems like it used the same driver for different paths, and after that it is removed.

Re: What the hell is a target triple?

#107

Post by o11c »

matheusmoreira wrote: post #98
guipsp wrote: post #74

Earlier quoted context omitted.

I mean, that is fine and all, but it doesn't really matter for making the software run correctly on systems that currently exist.

It works fine on current Linux systems. We can have freestanding executables that talk to Linux directly and link against zero system libraries. It's just that those executables are going to have to resolve names all by themselves. Chances are they aren't going to do it exactly like glibc does. That may or may not be a problem.

Historically, when DNS breaks in a not-glibc environment, it's very often found to in fact be a violation of some standard by the not-glibc, rather than a program that fails to document a glibc dependency.

Re: What the hell is a target triple?

#108

Post by o11c »

tialaramex wrote: post #97
steveklabnik wrote: post #50

Earlier quoted context omitted.

I have intense respect for the history of gcc, but everything about using it screams that it's stuck in the past. LLVM has a lot of problems, but it feels significantly more modern. I do wish we had a "new LLVM" doing to LLVM what it did to gcc. Just because it's better doesn't mean it's perfect. Basically, you can respect history while also being honest about the current state of things. But also, doing so requires…

Their IR is a mess. So a "new LLVM" ought to start by nailing down the IR. And as a bonus, seems to me a nailed down IR actually is that portable assembly language the C people keep telling us is what they wanted. Most of them don't actually want that and won't thank you - but if even 1% of the "I need a portable assembler" crowd actually did want a portable assembler they're a large volume of customers from day one.

Having tried writing plugins for both, I very much prefer GCC's codebase. You have to adapt to its quirks, but at least it won't pull the rug from under your feet gratuitously. There's a reason every major project ends up embedding a years-old copy of LLVM rather than just using the system version.

If you're ignoring the API and writing IR directly there are advantages to LLVM though.

Re: What the hell is a target triple?

#109

Post by matheusmoreira »

o11c wrote: post #103
matheusmoreira wrote: post #91

Earlier quoted context omitted.

It also focuses exclusively on sections. I wish it had at least mentioned segments, also known as program headers. Linux kernel's ELF loader does not care about sections, it only cares about segments. Sections and segments are more or less the same concept: metadata that tells the loader how to map each part of the file into the correct memory regions with the correct memory protection attributes. Biggest difference…

I wouldn't call them "same concept" at all. Segments (program headers) are all about the runtime (executables and shared libraries) and are low-cost. Sections are all about development (.o files) and are detailed. Generally there are many sections combined into a single segment, other than special-purpose ones. Unless you are reimplementing ld.so, you almost certainly don't want to touch segments; sections are far ea…

> I wouldn't call them "same concept" at all.

They are both metadata about file extents and their memory images.

> sections are far easier to work with

Yes. They are not, however, loaded into memory by default. Linkers do not generate LOAD segments for section metadata since they are not needed for execution. Thus it's impossible for a program to introspect its own sections without additional logic and I/O to read them into memory.

> Also, normally you just just call `getauxval`, but if needed the type is already named `ElfW(auxv_t)*`.

True. I didn't use it because it was not available. I wrote my article in the context of a freestanding nolibc program.

Re: What the hell is a target triple?

#110

Post by o11c »

matheusmoreira wrote: post #109
o11c wrote: post #103

Earlier quoted context omitted.

I wouldn't call them "same concept" at all. Segments (program headers) are all about the runtime (executables and shared libraries) and are low-cost. Sections are all about development (.o files) and are detailed. Generally there are many sections combined into a single segment, other than special-purpose ones. Unless you are reimplementing ld.so, you almost certainly don't want to touch segments; sections are far ea…

> I wouldn't call them "same concept" at all. They are both metadata about file extents and their memory images. > sections are far easier to work with Yes. They are not, however, loaded into memory by default. Linkers do not generate LOAD segments for section metadata since they are not needed for execution. Thus it's impossible for a program to introspect its own sections without additional logic and I/O to read th…

Right, but you can just use the section start/end symbols for a section that already goes into a mapped segment.
Post reply on HN