Refactor ELF utils from rt.backtrace.elf and rt.sections_elf_shared to core.internal.elf.{dl,io} #2330
Conversation
Thanks for your pull request and interest in making D better, @kinke! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please see CONTRIBUTING.md for more information. If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment. Bugzilla references
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing Ddoc documentation for all new public symbols.
src/core/elf.d
Outdated
} | ||
} | ||
|
||
dl_phdr_info info; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want this to be directly exposed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so; rt.sections_elf_backtrace
currently needs it for the TLS stuff, and I don't want to abstract it fully away, particularly since the struct is OS-dependent.
Do we really want this in |
That was my main goal, letting the user have access to this functionality too. E.g., we could presumably use it in LDC to parse the dependencies of an .so to be linked; if it depends on shared druntime/Phobos, LDC would use |
But why |
Well, because we need the stuff in druntime too. A higher level lib can always build on it. |
I don't think it's wise to have a platform-specific module in a common place. |
I'm totally flexible wrt. final place of this; it could live in |
Needs rebase and fix merge. |
src/core/elf.d
Outdated
@nogc nothrow: | ||
this(ref const ElfFile file, size_t index) | ||
{ | ||
assert(Elf_Shdr.sizeof == file.ehdr.e_shentsize); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tried my upcoming Android commit for #2325 with this pull, but it segfaults here: will look into why. In the meantime, turn this into an abort
message, just as you did with #2324, so it exits immediately rather than repeatedly trying to throw an exception and then segfaulting. I'm doing the same in my Android pull, replacing asserts with abort messages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably because this module currently only supports native ELF files, i.e., corresponding with the host, which is quite a serious limitation.
I don't think aborting here is a good idea; #2324 was different, as the chances for the GC not being initialized yet/already shut down are very high for that code, so throwing in that code is to be avoided.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm building on Android itself, but it's likely that some of the ELF definitions are different there.
As for aborting here, I will be using this on Android before the GC is initialized, but I didn't check how you're using it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't matter how I'm using it; if this code is in core
, the user is supposed to be able to use it too, so I don't want to abort in case the ELF file doesn't match; it might as well just be an attempt of opening the file as e.g. 32-bit ELF file.
So I should actually change the assertion to a normal throw (oh well, not sure how well that plays with nothrow
and the backtrace code). Edit: Ah, that's the ElfSectionHeader
ctor; using that one should be done after checking ElfFile.isValid()
, so the assertion is fine IMO.
@kinke, any chance we can get this into the final 1.13 release? I'd like to use it for Android too. |
I don't think so; I'm not too keen on having this pretty big diff wrt. upstream in LDC. |
No, I mean do you think you can get it merged here in time for a cherrypick before the 1.13 release? |
Lol, no way! :) |
Heh, OK, I still need to look into why this pull doesn't work on Android anyway, maybe I'll just try to get it working for the native Android builds of LDC. |
07c90db
to
e716ef7
Compare
Incl. some minor refactoring (pointer to ref, make `findSectionByName()` an ElfFile method, add `findSectionHeaderByName()` convenience method etc.).
I.e., allowing to read non-native ELF files too. The byte order must match the target's though.
Rebased and moved to |
Let's stick to |
Ping ding dong, another month has passed by. |
@kinke This pull request introduced a regression: |
A common place for working with ELF binaries, accessible by user code as well and providing a bit more convenience.