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

111–120 of 139 posts

Re: What the hell is a target triple?

#111

Post by plorkyeran »

ComputerGuru wrote: post #72

Great article but I was really put off by this bit, which aside from being very condescending, simply isn't true and reveals a lack of appreciation for the innovation that I would have thought someone posting about target triples and compilers would have appreciated: > Why the Windows people invented a whole other ABI instead of making things clean and simple like Apple did with Rosetta on ARM MacBooks? I have no ide…

The thing named Rosetta (actually Rosetta 2) for the x86_64 -> ARM transition is technologically completely unrelated to the PPC -> x86 Rosetta, and has none of the problems you mention. There's no user-observable difference between a program using Rosetta and a native program in modern macOS, and porting programs which didn't have any assembly or other CPU-arch-specific code was generally just a matter of wrangling your build system.

Re: What the hell is a target triple?

#112

Post by matheusmoreira »

o11c wrote: post #110
matheusmoreira wrote: post #109

Earlier quoted context omitted.

> 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.

Can you show me how that would work?

It's trivial to put arbitrary files into sections:

  objcopy --add-section program.files.1=file.1.dat \
          --add-section program.files.2=file.2.dat \
          program program+files
The problem is the program.files.* sections do not get mapped in by a LOAD segment. I ended up having to write my own tool to patch in a LOAD segment into the segments table because objcopy does not have the ability to do it.

Even asked a Stack Overflow question about this two years ago:

https://stackoverflow.com/q/77468641

The only answer I got told me to simply read the sections into memory via /proc/self/exe or edit the segments table and make it so that the LOAD segments cover the whole file. I eventually figured out ways to add LOAD segments to the table. By that point I didn't need sections anymore, just a custom segment type.

Re: What the hell is a target triple?

#113

Post by plorkyeran »

AceJohnny2 wrote: post #26

Offtopic, but I'm distracted by the opening example: > After all, you don’t want to be building your iPhone app on literal iPhone hardware. iPhones are impressively powerful, but you wouldn't know it from the software lockdown that Apple holds on it. Example: https://www.tomsguide.com/phones/iphones/iphone-16-is-actual... There's a reason people were clamoring for Apple to make ARM laptops/desktops for years before A…

iPhones have terrible heat dispersion compared to even a fanless computer like a macbook air. You get a few minutes at full load before thermal throttling kicks in, so you could do the occasional build of your iPhone app on an iPhone but it'd be pretty terrible as a development platform.

At work we had some benchmarking suites that ran on physical devices and even with significant effort put into cooling them they spent more time sleeping waiting to cool off than actually running the benchmarks.

Re: What the hell is a target triple?

#115

Post by o11c »

matheusmoreira wrote: post #112
o11c wrote: post #110

Earlier quoted context omitted.

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

Can you show me how that would work? It's trivial to put arbitrary files into sections: objcopy --add-section program.files.1=file.1.dat \ --add-section program.files.2=file.2.dat \ program program+files The problem is the program.files.* sections do not get mapped in by a LOAD segment. I ended up having to write my own tool to patch in a LOAD segment into the segments table because objcopy does not have the ability…

The whole point of section names is that they mean something. If you give it a name that matches `.rodata.*` it will be part of the existing read-only LOADed segments, or `.data.*` for (private) read-write.

Use `ld --verbose` to see what sections are mapped by default (it is impossible for a linker to work without having such a linker script; we're just lucky that GNU ld exposes it in a sane form rather than hard-coding it as C code). In modern versions of the linker (there is still old documentation found by search engines), you can specify multiple SECTIONS commands (likely from multiple scripts, i.e. just files passed on the command line), but why would you when you can conform to the default one?

You should pick a section name that won't collide with the section names generated by `-fdata-sections` (or `-ffunction-sections` if that's ever relevant for you).

Re: What the hell is a target triple?

#116

Post by rendaw »

ycombinatrix wrote: post #84
peterldowns wrote: post #24

Some other sources of target triples (some mentioned in the article, some not): rustc: `rustc --print target-list` golang: `go tool dist list` zig: `zig targets` As the article point out, the complete lack of standardization and consistency in what constitutes a "triple" (sometimes actually a quad!) is kind of hellishly hilarious.

at least we don't have to deal with --build, --host, --target nonsense anymore

You do on Nix. And it's as inconsistently implemented there as anywhere.

Re: What the hell is a target triple?

#117

Post by damagednoob »

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

When developing a small program for my Synology NAS in Go, I'm sure I had to target a specific version of glibc.

Re: What the hell is a target triple?

#118

Post by matheusmoreira »

o11c wrote: post #115
matheusmoreira wrote: post #112

Earlier quoted context omitted.

Can you show me how that would work? It's trivial to put arbitrary files into sections: objcopy --add-section program.files.1=file.1.dat \ --add-section program.files.2=file.2.dat \ program program+files The problem is the program.files.* sections do not get mapped in by a LOAD segment. I ended up having to write my own tool to patch in a LOAD segment into the segments table because objcopy does not have the ability…

The whole point of section names is that they mean something. If you give it a name that matches `.rodata.*` it will be part of the existing read-only LOADed segments, or `.data.*` for (private) read-write. Use `ld --verbose` to see what sections are mapped by default (it is impossible for a linker to work without having such a linker script; we're just lucky that GNU ld exposes it in a sane form rather than hard-cod…

That requires relinking the executable. That is not always desirable or possible. Unless the dynamic linker ignores the segments table in favor of doing this on the fly... Even if that's the case, it won't work for statically linked executables. Only the dynamic linker can assign meaning to section names at runtime and the dynamic linker isn't involved at all in the case of statically linked programs.

Re: What the hell is a target triple?

#119

Post by Joker_vD »

> no one calls it x64 except for Microsoft. And even though it is fairly prevalent on Windows, I absolutely give my gamedev friends a hard time when they write x64.

So, it turns out, actually a lot of people call it x64 — including author's own friends! — it's just that the author dislikes it. Disliking something is fine, but why claim outright falsehood which you know first-hand is false?

Also, the actual proper name for this ISA is, of course, EM64T. /s

> The fourth entry of the triple (and I repeat myself, yes, it’s still a triple)

Any actual justification except the bald assertions from the personal preferences? Just call it a "tuple", or something...

Re: What the hell is a target triple?

#120

Post by IAmLiterallyAB »

> However, due to the runaway popularity of LLVM, virtually all compilers now use target triples.

That's a wild take. I think its pretty universally accepted the GCC and the GNU toolchain is what made this ubiquitous.

Also, the x32 ABI is still around, support is still around, I don't know where the author got that notion

Post reply on HN