src: retrieve .text coordinates for large pages

[gabrielschulhof]

After locating the in-memory base address of the Node.js executable
using dl_iterate_phdr(3) we open the on-disk executable file and
extract the address and size of the .text section. We then add the
in-memory base address to the offset to locate the .text section in
memory.

This approach removes the need for a symbol to tell us where the
.text section is located, and, unlike the previous approach,
guarantees that we will always have the entire .text section
available for re-mapping.

Signed-off-by: @gabrielschulhof

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/31049/

[bnoordhuis]

I don't think this is a good idea for two reasons:

1. Won't work when /proc isn't mounted.

2. Does a lot of extra file I/O at startup.

The second one in particular is a deal breaker.

[bnoordhuis]

We used to have a DISALLOW_COPY_AND_ASSIGN macro for this but we moved to just writing them out by hand, see #26634. Can you do that here too?

[bnoordhuis]

open(2) is interruptible by a signal. You should retry on EINTR:

Suggested change

	fd_ = open(fname, O_RDONLY);
	do
	fd_ = open(fname, O_RDONLY);
	while (fd == -1 && errno == EINTR);

As well, stat + open is race-y. Not that it really matters here but you still should do open + fstat. :-)

[bnoordhuis]

Can you if (errno == EINTR || errno == EINPROGRESS) return;?

close(2) is interruptible but you shouldn't retry - it's going to get closed anyway - and printing an error isn't useful.

[gabrielschulhof]

I added this.

[bnoordhuis]

Suggested change

	if (std::string(section_name) == ".text") {
	if (0 == strcmp(section_name, ".text")) {

It's kind of wasteful to create a heap-allocated throwaway string. It's probably going to be stored inline for short strings but you get my point.

[bnoordhuis]

This assumes /proc is mounted but that need not be the case.

[gabrielschulhof]

@bnoordhuis I checked the startup time wrt. master and it does not seem to be different at all with this change. This feature used to rely on reading /proc/self/maps instead of dl_iterate_phdr(). There was file I/O and reliance on /proc in that. IMO removing the complicated build process and the groping in the dark of the segment with heuristics like

node/src/large_pages/node_large_page.cc

Lines 163 to 168 in f64c640

	if (dl_params->reference_sym >= start &&
	dl_params->reference_sym <= end) {
	dl_params->start = start;
	dl_params->end = end;
	return 1;
	}

and

node/src/large_pages/node_large_page.cc

Lines 205 to 209 in f64c640

	if (lpstub_start > dl_params.start && lpstub_start <= dl_params.end) {
	Debug("Hugepages info: Trimming end for lpstub: %p\n",
	reinterpret_cast<void*>(lpstub_start));
	dl_params.end = lpstub_start;
	}

may be worth the renewed reliance on /proc.

[gabrielschulhof]

@bnoordhuis I also added a Debug() in MappedFilePointer::Reset in case it fails because of a lack of /proc.

[bnoordhuis]

I checked the startup time wrt. master and it does not seem to be different at all with this change.

The kernel reads the ELF header on startup so it's often in the page cache, but when it's not and you're running node off your Raspberry Pi's SD card, you're going to notice.

This feature used to rely on reading /proc/self/maps instead of dl_iterate_phdr(). There was file I/O and reliance on /proc in that.

procfs is a virtual fs though, there's no actual disk I/O taking place.

[gabrielschulhof]

@bnoordhuis fair enough.