User Details
- User Since
- Sep 21 2015, 12:36 AM (279 w, 2 d)
Today
Yesterday
Hi guys.
I am sorry for pinging this too early, but I am planning a ~6 weeks vacation starting from 1st of february
and I wonder if there is something I can do for this to land it or if there are any concerns about this change?
E.g. it seems that the expected behavior of llvm-objcopy would be to drop the sh_link for symbol table in this case. Because it is of SHT_NOBITS type.
Perhaps I'd wait from some input from @MaskRay as he was the author of the test case I think.
It turns out this wasn't NFC, one of LLDB test cases started to crash.
I've fixed it in rG2a33b092f5b175a21680b3980ff2019bc1c65b12.
I like this approach.
Mon, Jan 25
- Addressed review comment.
As far I understand, looking on the description of D94239, the message on z/OS looks like "EDC5129I No such file or directory.".
I guess the EDC5129I is a stable error code? So why not to check for a possible EDC5129I prefix word instead of .*?
A minor nit from me, the rest looks fine.
This looks to me it solves a specific corner case, but I really don't feel I have enough knowledges about embedded world/scripts to say whether it is a good or bad thing to support it.
It seems matches to what GNU ld/gold do. I'll add Peter who I guess might have an opinion about this.
Fri, Jan 22
- Addressed review comments.
D95140 was posted instead.
- Addressed review comments.
Thu, Jan 21
LGTM with a nit, please wait for others.
Wed, Jan 20
This LGTM, but please wait for others.
@MaskRay, are you OK with it?
Tue, Jan 19
Ping.
- Added test cases.
- Addressed review comment.
- Addressed review comments.
Mon, Jan 18
- Format.
- Addressed review comments.
Fri, Jan 15
An alternative to this could probably be changing the Writer<ELFT>::assignFileOffsets()
It has the following loop:
Thu, Jan 14
- Addressed review comments.
FWIW, I think we could support this, but I'd implement it in a much more trivial way.
E.g. I think it can be just a 2 lines loop which would iterate over all output sections and print their names ans sizes.
No need to sort them or to calculate fields width.
Wed, Jan 13
I am not the right person to review this, I don't work on MC or MC/ARM. I think you should add people who mantains MC/ARM and/or may be authors of these tests.
The change looks good to me though.
Ok. I've used the following piece of code to construct a 1Gb of random compressed data and estimated
the difference between the old and the new code in Release.