- User Since
- Sep 17 2015, 9:03 AM (278 w, 2 d)
As I understand it, this is about what library call should be made when there is an eabi target such as arm-none-eabi which should target the Run Time ABI for the Arm Architecture https://github.com/ARM-software/abi-aa/blob/master/rtabi32/rtabi32.rst and other Arm targets such as Linux or Android. I think if we're arguing from the specification then clang is compliant with the eabi, so relocatable objects produced by clang should be compatible with eabi compliant toolchains that supply the eabi functions, this includes non GNU toolchains as well like IAR.
Thu, Jan 14
Thanks for working on this. It will be very useful for people using GCC yet using LLD as a linker on AArch64. Will try and take a look later today, if not then I should have some time tomorrow morning.
Fri, Jan 8
LGTM, may be worth waiting for any other comments.
Wed, Jan 6
Dec 17 2020
No objections from me, looks like a sensible change.
Dec 16 2020
The calculation looks good to me. It is logically equivalent to that given in the reference manual
Dec 15 2020
Dec 10 2020
Thanks for working on this. It looks like it implements the ABI correctly (see PR for links to the specification and GCC/Glibc details).
Nov 24 2020
Looks good to me. Thanks for tidying this up.
Radio silence so far; I think no news is good news applies in this case. I'm happy to say no objections.
Nov 19 2020
Personally I'm in favour of clang and gcc behaving the same way unless there is a good reason not to. I've shared the review internally to see if anyone has any concerns. May be worth informing the clang built linux community to see if they will need to make any alterations as a result.
Nov 17 2020
No objections from me. Although unrelated to the patch, isLSDA might be better called fromFDE, or couldBeLSDA? Maybe one for a later follow up.
LGTM, with one suggestion of a name change. I've checked the GNU ld behaviour against the green test changes and LLD matches.
Nov 12 2020
Assuming there are no problems with the bots or other downstream builds, please update the PR with a link to this review.
Now committed. Commit message has your name and email address.
Thanks for updating the comments. If the lexical ordering is going to work out the same I don't have any objections.
Thanks for the updates, LGTM too.
Nov 11 2020
Will take another look tonight.For reference, I tried helping out someone last year with https://bugs.llvm.org/show_bug.cgi?id=44698 I think they had old objects, or a an old GCC on their system and it was mixing with a modern clang. Maybe worth a read through.
Nov 10 2020
It took a lot of staring at that bit of code to work out what was going on. If I have understood it correctly. In particular I got confused with the sizeBefore and sizeLastSort with sizeBefore being the larger value. It took me a while to spot the continue. If I've understood correctly:
- sizeBefore is really sizeOfRetBeforeNextSort
- sizeLastSort is really sizeOfRetAfterPreviousSort
If possible could we use Prev rather than Last as it is more specific. Last can mean the last one we went by, or the last one in the list. I strongly recommend adding something like Next to sizeBefore so that it is clear that sizeBefore >= sizeLastSort.
Looks OK to me. Will be best to see if George has any comments about how to do the parsing.
Apologies for being so quiet recently. It looks like this is changing .ctors/.dtors away from SORT_BY_NAME when they aren't mixed with .init_array.
Nov 4 2020
This looks good to me. The __ARM_FP feature test macro is defined in the ACLE and 0x8 is the right flag to check for Double precision support. I've tested at least one single precision only build.
Oct 28 2020
I've left a few small suggestions but overall no objections. Given that this is the default BFD behaviour and programs that have only been linked with LLD are not likely to use common; I think that if this behaviour is to be put under an option, it is on by default. This will permit users to use both GNU ld and lld with the same command line.
Oct 27 2020
If we issue a warning instead, users will only notice the semantic difference when they use -Wa,--fatal-warnings. We can classify the potential risks on whether .local is used:
- .local is used: .local is a very rare directive.
- .local is not used: the issue is about .weak and .globl . This represents a semantic difference between MC and GNU ld. There may be a few more but I doubt there can be more than a few. Can we try error first and switch to a warning if it turns out to be a problem?
Oct 26 2020
Personally I'd err on the side of consistency with binutils. If they are happy to go to an error then we can. If they aren't then I recommend that we warn rather than error as we risk breaking builds for working software and it isn't always easy to get source code fixed. Not got a strong opinion though so happy to go with the consensus.
Oct 22 2020
LGTM too. Apologies for the delay. This looks like it is consistent with the ELF specification.
Oct 21 2020
LGTM. If we are marking a section live it makes sense to mark its dependent sections live.
Oct 14 2020
I don't have any objections. My comment in the thread was more along the lines that dependent libraries could interact with whole-archive in hard to predict ways. I'm happy to have dependent libraries ignore whole-archive. I'm fine with MaskRay accepting when he is happy.
Sep 29 2020
Looks good to me. Thanks very much for adding the functionality.
Sep 28 2020
LGTM. Agree that it should be bit31 that is sign extended. Apologies for not catching this last time.
Sep 25 2020
What's here looks good to me to.
Sep 24 2020
I'll try and take a look tomorrow.
Sep 23 2020
Thanks for the update. LGTM. Happy to see other parts done in follow up commits
Sep 22 2020
I think there may still be problems in a non-relocatable ELF file when there is more than one executable output section as there is only one .ARM.exidx output section and only one sh_link.
Sep 21 2020
Looks good to me. Thanks for cleaning this up, it will be of great help to 32-bit bots.
Sep 17 2020
LGTM too, thanks for adding the tests.
Sep 9 2020
Thanks for the update I'm happy with the edits.
Will have to have a think. My initial reaction to "apply this file only when these conditions hold" is akin to moving part of the build system into the linker. It could be done, but I'm not sure it should be. For example if there were a linker script it would have to precisely match the inputs to make sense.
Sep 4 2020
I've put some comments, mostly concentrating on the early part. I've not had a chance to go through the examples at the bottom in detail. I can't spot anything obviously wrong though.
Sep 2 2020
I don't have any objections to the approval. Thanks for updating the comment.
Sep 1 2020
Thanks for the update and sorry to take so long to comment. I can't see anything immediately wrong and I think limiting this to fragments in the same subsection makes sense.
I had a look in Levine's Linkers and Loaders book to see if I could find any source for back-references, all I could find was in 6.4 "Not all linkers do this; many just make a single sequential pass over the directory and miss any backwards depedencies from a file to another file earlier in the library. Tools like tsort and lorder can minimize the difficulty of using single-pass linkers but it's not uncommon for programmers to explicitly list the same library several times on the linker command line to force multiple passes and thus finally resolve all symbols."
Aug 26 2020
Thanks for putting this together, looks good. I've added a few suggestions, and some typo spots.
Aug 25 2020
LGTM too, I'm happy my comments were addressed, thanks.
Aug 24 2020
Overall looking good. I think there may be an endianness problem with reinterpret_cast although I could easily be wrong without testing (I don't think we have a target that uses .note.gnu.property with big-endian support in LLD).
Aug 20 2020
Had a chance to look over lunch. Thanks looks good to me too.
Not had a chance to look into the changes in detail yet, but on first glance it looks good. Given that the compiler uses STT_FUNC for the entry of a symbol I think it is reasonable to retain the type only for an alias.
Aug 19 2020
In ELF the last paragraph of the section on STT_COMMON only mentions that a dynamic linker may change its resolution rules to prefer non-common over a common definition. I'm guessing extending this to static linker is something that some other linkers have done and there are some programs that currently depend on that behaviour.
Symbols with type STT_COMMON label uninitialized common blocks. In relocatable objects, these symbols are not allocated and must have the special section index SHN_COMMON (see below). In shared objects and executables these symbols must be allocated to some section in the defining object.
Aug 14 2020
Given that it is possible to write a linker script that does work with *(pattern1 pattern2) then I don't have any objections. I've tentatively approved as it looks like was the most cautious here.
Thanks for the update. I'm happy with the changes. I've tentatively approved, James/Edd please shout if you have any objections?
Aug 13 2020
Just to check I understand.
Aug 12 2020
I think this should be ok for .ARM.exidx sections as they have a SHF_LINK_ORDER dependency which prevents them from being merged in relocatable links.
Aug 11 2020
Looks good to me. Will be worth seeing if MaskRay has any comments.
Aug 10 2020
Thanks for the update, I'm happy when George is.
Thanks for spotting that. I'd personally prefer to fix in the linker script, rather than make the code RW but I don't have a strong preference.
Simplification looks good to me. I'm not sure about the test changes as I would have expected the change to be NFC. If these are test improvements it will be worth altering separately.
Aug 6 2020
I agree it's not what I'd like. I'm not sure how to react to MaskRays comment. The top of the ClangCommandLineReference.rst says:
------------------------------------------------------------------- NOTE: This file is automatically generated by running clang-tblgen -gen-opt-docs. Do not edit this file by hand!! -------------------------------------------------------------------
This uses Options.td to generate the file. I don't know how true this is anymore given that both files are checked in. They may have been separated. I've seen at least one instance in the log where the whole file has been regenerated.
Aug 5 2020
Yes. I think the consensus was to match the GCC behaviour, I'll abandon the revision.
FWIW this looks good to me too.
No objections from me either. I guess LGTM if George's last comment can be resolved.
uploaded diff with both Options.td and ClangCommandLineReference.rst
I agree I think it is best to err on the side of correctness. As I understand it we could do better (merge more sections) but this would involve pulling apart .eh_frame sections to show equivalence. I think that could come later.
My apologies for not commenting earlier. I haven't had a lot of spare time and I only have a weak opinion, certainly far weaker than the other commenters.
Aug 4 2020
I agree with MaskRay that if we do support the feature then we should make sure it works or document its limitations, even if our limitations are "Implemented to the degree that it supports the FreeBSD Kernel, we recommend producing an ELF file and using llvm-objcopy --output-target=binary."
Aug 1 2020
I do have some sympathy with wanting to use a command line option to keep an individual section from the command line as it has been useful in Arm's proprietary linker, although this is mainly due to the convenience of not having to create or modify another file.
Jul 31 2020
It is a pity that the section name is not a valid C identifier otherwise start_ and stop_ would have been generated automatically.
Jul 29 2020
Jul 20 2020
This looks good to me. Regardless of whether we allow --gc-sections it will be worth getting this right for /DISCARD/. Will be worth waiting to see if there are any further comments from other reviewers.
I guess if the use case for -r is a kernel module then garbage collection can make sense as the "object" is not relinked. What happens when there is no GC root? I think it will be worth detecting that and turning GC off as otherwise everything will get removed which is unlikely to be what was wanted.
Jul 18 2020
Jul 17 2020
I'll take a look over the weekend, also at D72904, apologies won't be able to get to it today.
Jul 13 2020
What would happen if there was a single .text section containing multiple functions, would that produce multiple .gcc_except_table sections each with a SHF_LINK_ORDER dependency on the single .text section? I think that this is OK as there are no other sections that refer to .gcc_except_table and there doesn't need to be a total order. Ideally we could have one .gcc_except_table section per associated .text section.
Jul 8 2020
Jul 7 2020
I think an option makes sense. I have a small reservation about making users order their matches on the command line. We should make it more explicit in the help and the manual, or try and sort the matches using a heuristic order of specificity, for example no wildcards is more specific than wildcards, longer text is more specific than shorter. Other than that I think it looks OK.
LGTM it looks like a good simplification. Worth waiting a little bit to see if there are any objections.
Jul 6 2020
LGTM, it looks like it is difficult to generate local dynamic from clang, although it is possible with GCC. I was able to make a test application, that also had the advantage of working for shared libraries and PIE as R_ABS does not in that case.
Jul 3 2020
Thanks, will take a look over the weekend. Would like to make sure all is well running some TLS test cases on a native Arm machine, fully expect it to be OK.
I'm ok with this as is. I'll need to check over what should be happening on Arm, but I think that can be done in a separate change.
Jul 1 2020
This looks OK to me, happy for George to approve . I'm not a Windows filesystem expert by any means, it seems like the rename then delete follows the pattern in https://boostgsoc13.github.io/boost.afio/doc/html/afio/FAQ/deleting_open_files.html though.
Jun 24 2020
Looks good to me. Agree that symbol versioning should be passed through in a relocatable link.
Jun 23 2020
Thanks for the update, I don't have any more comments. Happy when MaskRay is happy.
Jun 19 2020
Jun 18 2020
I think that this is highly likely to be a typo, it looks like it dates to the contribution of compiler-rt so there isn't any history we can use. I believe that compiler-rt builtins originated in Apple so there is a possibility that SOFTFP was used in the compiler at contribution time. If you wanted to be safe you could support both SOFTFP and SOFT_FP but I don't think that is necessary. I would like to think that for a soft-fp target the tests for these functions fail or are at least xfailed at the moment. Are you able to compile the tests for a soft-fp target to check?
Jun 16 2020
I only partially followed the discussion on llvm-dev. The resolution sounds sensible to me. Will be good to get someone involved in the upstream discussion to check it over.
Jun 12 2020
Looking good so far. Would be good to add a range extension thunk test case. For example:
.section .text.1, "ax", %progbits .global _start .type _start, %function _start: .word callee@PLT - .