Page MenuHomePhabricator
Feed Advanced Search

Fri, Oct 25

abrachet accepted D69421: [libc] Header generation scheme..

LGTM I see no problems from what is here. I'd also like to say that the emphasis on writing docs for all of this is something I'm really happy to see.
I look forward to seeing how the generator works. I am also cautiously optimistic about how well this mechanism will work to create more exotic functions and typedefs. signal(3) and jmp_buf will surely be interesting interesting :)

Fri, Oct 25, 4:31 PM · Unknown Object (Project)
abrachet added inline comments to D69421: [libc] Header generation scheme..
Fri, Oct 25, 3:24 PM · Unknown Object (Project)

Oct 18 2019

abrachet added a comment to D69188: [llvm-objcopy] Preserve .ARM.attributes section when stripping files.

Seems like a hack, no? What about using --keep-section when you need it? You say its not strictly needed on modern systems and the problem is with the dlopen implementation of these older libcs, and not llvm-objcopy, so I would be hesitant to add something like this especially given we have a solution with --keep-section

Oct 18 2019, 12:50 PM · Restricted Project
abrachet added inline comments to D69093: [llvm-objcopy] --add-symbol: fix crash if SHT_SYMTAB does not exist.
Oct 18 2019, 9:06 AM · Restricted Project

Oct 13 2019

abrachet added inline comments to D68931: [clang] [clang-offload-bundler] Fix finding installed llvm-objcopy.
Oct 13 2019, 2:53 PM · Restricted Project
abrachet accepted D68931: [clang] [clang-offload-bundler] Fix finding installed llvm-objcopy.
Oct 13 2019, 2:44 PM · Restricted Project

Oct 7 2019

abrachet added a comment to D67867: [libc] Add few docs and implementation of strcpy and strcat..

My earlier question is about why we need the namespace __llvm_libc at all. From libc/src/string/strcat/strcat_test.cpp I conclude it is for unit testing in an environment that already has a libc (gtest). This should probably be documented.

Can we do things the other way round? No namespace, no __llvm_libc_ prefix. Add the -ffreestanding compiler flag and just define strstr, open, etc in the global namespace. In unit tests, invoke llvm-objcopy --redefine-syms= to rename strstr to __llvm_libc_strstr, and call __llvm_libc_strstr in the tests. For functions that affect global states, gtest will not be suitable. It is good to think how the tests will be organized in the current early stage.

Oct 7 2019, 2:52 PM · Unknown Object (Project), Restricted Project

Sep 24 2019

abrachet added a comment to D67656: [llvm-objcopy] Add --set-section-alignment.

Looks like the author of that patch submitted a new patch to accept alignment of power of twos not 2^<align> after James’ comment :)

Sep 24 2019, 12:34 PM · Restricted Project

Sep 23 2019

abrachet added a comment to D67656: [llvm-objcopy] Add --set-section-alignment.

I'm very happy to see this change, but I hesitate to diverge in behaviour from GNU's behaviour. I certainly prefer --set-section-alginment to set it to an arbitrary alignment though, so I think we need to lean on the GNU maintainers to change their end.

The behavior difference is also my concern, so I hold off on this patch. I argue at https://sourceware.org/bugzilla/show_bug.cgi?id=24942#c9 that --set-section-alignment .foo=8 => sh_addralign=256 is counterintuitive. Please chime in if you feel the same.

Sep 23 2019, 10:06 PM · Restricted Project

Sep 17 2019

abrachet added inline comments to D67656: [llvm-objcopy] Add --set-section-alignment.
Sep 17 2019, 7:56 PM · Restricted Project

Sep 5 2019

abrachet committed rGdfacf8851e93: Fix rL371162 again (authored by abrachet).
Fix rL371162 again
Sep 5 2019, 8:35 PM
abrachet committed rL371164: Fix rL371162 again.
Fix rL371162 again
Sep 5 2019, 8:35 PM
abrachet committed rG27d42af6034b: Fix failing test from rL371162 (authored by abrachet).
Fix failing test from rL371162
Sep 5 2019, 7:57 PM
abrachet committed rL371163: Fix failing test from rL371162.
Fix failing test from rL371162
Sep 5 2019, 7:57 PM
abrachet committed rL371162: [yaml2obj] Make e_phoff and e_phentsize 0 if there are no program headers.
[yaml2obj] Make e_phoff and e_phentsize 0 if there are no program headers
Sep 5 2019, 7:28 PM
abrachet committed rG0b69c59656f5: [yaml2obj] Make e_phoff and e_phentsize 0 if there are no program headers (authored by abrachet).
[yaml2obj] Make e_phoff and e_phentsize 0 if there are no program headers
Sep 5 2019, 7:28 PM
abrachet closed D67054: [yaml2obj] Make e_phoff and e_phentsize 0 if there are no program headers.
Sep 5 2019, 7:28 PM · Restricted Project
abrachet updated the diff for D67054: [yaml2obj] Make e_phoff and e_phentsize 0 if there are no program headers.

Addressed review comments.

Sep 5 2019, 7:12 PM · Restricted Project

Sep 2 2019

abrachet updated the diff for D67054: [yaml2obj] Make e_phoff and e_phentsize 0 if there are no program headers.

Changed test comment.

Sep 2 2019, 10:10 PM · Restricted Project
abrachet updated the diff for D67054: [yaml2obj] Make e_phoff and e_phentsize 0 if there are no program headers.

Made e_phentsize 0 when there are no program headers too.

Sep 2 2019, 9:52 PM · Restricted Project

Sep 1 2019

abrachet updated the diff for D67054: [yaml2obj] Make e_phoff and e_phentsize 0 if there are no program headers.

Changed test name

Sep 1 2019, 10:14 PM · Restricted Project
abrachet created D67054: [yaml2obj] Make e_phoff and e_phentsize 0 if there are no program headers.
Sep 1 2019, 3:15 PM · Restricted Project

Aug 28 2019

abrachet added a comment to D66403: Create MutableObjectWriter class.

I didn't get to all comments yet, and I also haven't added more tests because currently the object file isn't being create properly. Once I am making a valid ELF file I will do more rigorous testing.

Aug 28 2019, 10:35 PM · Restricted Project
abrachet updated the diff for D66403: Create MutableObjectWriter class.

Addressed review comments

Aug 28 2019, 10:14 PM · Restricted Project

Aug 26 2019

abrachet added a parent revision for D66403: Create MutableObjectWriter class: D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6].
Aug 26 2019, 1:45 PM · Restricted Project
abrachet added a child revision for D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6]: D66403: Create MutableObjectWriter class.
Aug 26 2019, 1:45 PM · Restricted Project
abrachet updated the diff for D66403: Create MutableObjectWriter class.

Fixed UB bug. Still doesn't write correctly, llvm-readelf says the shstrtab is not null terminated, presumably the other sections are written poorly too.

Aug 26 2019, 1:43 PM · Restricted Project

Aug 25 2019

abrachet added a comment to D66063: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 5].

I was discussing this issue with a colleague yesterday, to see if there's a clear path forward. He suggested that it might have made more sense to just modify the ELFObjectFile interface directly, rather than adding the MutableELFObject class.

So remove MutableELFObject and put it in ELFObjectFile? This might let ELFObjectFile no longer depend on ELFFile but I'm not entirely sure on that. It's also worth noting that as @rupprecht has pointed out many methods are now linear not constant so without doing some changes (could even be a boolean to track whether any modifications have been made) it probably shouldn't be used yet.

You could also mess about with more objects to hide away the dangerous methods by doing this.

Is this in reference to the earlier point about just modifying ELFObjectFile?

I believe the virtual table will still exist, if you reinterpret_cast to the base class, and so it's safe enough to work with the base class this way, but it feels a bit wrong to be doing so, as it circumvents the whole point of why we are doing the inheritance this way at all.

I think it isn't that bad to cast this to a base class if we know the methods that will be called in that context will always be safe to call. It is much more controlled this way but still bugs can happen if the base class methods get change. I don't feel too strongly.

One advantage of private inheritance over a private member, I believe, is that you should be able to use the using directive to pull base-class functions into the public interface of the sub-class:

Oh that's very useful I didn't know about that.

Aug 25 2019, 10:30 PM · Restricted Project
abrachet updated the diff for D66403: Create MutableObjectWriter class.

Use right diff

Aug 25 2019, 9:25 PM · Restricted Project
abrachet updated the diff for D66403: Create MutableObjectWriter class.

Put option to use writer behind flag. Other large changes

Aug 25 2019, 9:25 PM · Restricted Project

Aug 24 2019

abrachet added inline comments to D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6].
Aug 24 2019, 9:55 PM · Restricted Project
abrachet updated the diff for D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6].

Addressed review comments

Aug 24 2019, 9:51 PM · Restricted Project

Aug 22 2019

abrachet added a comment to D64281: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 1].

I've been thinking about this, is size_t safe to use? Some methods from inherited classes use uint64_t on my machine its fine because even unsigned long and unsigned long long have the same width and sign but on a 32 bit machine I think that assigning to a size_t (which is guaranteed to be word size, I think) from a uint64_t might produce a warning. I don't think there are any examples in this patch, but this seemed like the best place to ask.

You should use size_t and consider casting for cases using uint64_t. In a 32-bit build, size_t is usually a 32-bit number (i.e. unsigned int), so theoretically, the compiler could produce warnings for truncation issues when converting from a uint64_t. Since the main thing these indexes are used for is for accessing a vector, the type should match the argument type of std::vector<T>::operator[], which is (usually) a size_t.

Aug 22 2019, 11:00 PM · Restricted Project
abrachet added a comment to D66063: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 5].
  1. Using private inheritance or making the ELFObjectFile a private member of MutableELFObject instead of a base class. This would require MutableELFObject to opt in into functions that we know to be safe to use, and wouldn't allow usage of other functions. This is safer, but could result in a fair amount of extra code. This might need to be combined with 1) too to fix the specific issues this patch addresses.

This approach (not private inheritance, but making ELFObjectFile a private member + exposing specific accessors) seems to be the least fragile approach, but also the most verbose one, e.g. you may have to implement/override all the methods of EF that are used in subclasses.

Aug 22 2019, 6:48 PM · Restricted Project
abrachet added inline comments to D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6].
Aug 22 2019, 2:43 PM · Restricted Project
abrachet updated the diff for D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6].

Use Optional<size_t> to represents parent segments. Addressed other comments.

Aug 22 2019, 2:34 PM · Restricted Project

Aug 21 2019

abrachet added a comment to D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6].

That should allow you to handle multiple levels of nesting/overlapping etc without too much difficulty.

Hmm if a segment had a list of its child segments, then couldn't layout be done recursively on each child segment? Would this not be more straight forward?

Aug 21 2019, 9:29 PM · Restricted Project
abrachet updated the diff for D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6].

Added parent segment to both section and segment types and methods to find parent segments

Aug 21 2019, 9:22 PM · Restricted Project
abrachet added inline comments to D64281: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 1].
Aug 21 2019, 6:38 PM · Restricted Project
abrachet added a comment to D64281: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 1].

I've been thinking about this, is size_t safe to use? Some methods from inherited classes use uint64_t on my machine its fine because even unsigned long and unsigned long long have the same width and sign but on a 32 bit machine I think that assigning to a size_t (which is guaranteed to be word size, I think) from a uint64_t might produce a warning. I don't think there are any examples in this patch, but this seemed like the best place to ask.

Aug 21 2019, 6:30 PM · Restricted Project
abrachet updated the diff for D65633: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 3].

Addressed comments

Aug 21 2019, 12:58 PM · Restricted Project

Aug 20 2019

abrachet updated the diff for D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6].

Use the right diff (!)

Aug 20 2019, 10:24 PM · Restricted Project
abrachet added inline comments to D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6].
Aug 20 2019, 10:16 PM · Restricted Project
abrachet updated the diff for D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6].

Addressed comments

Aug 20 2019, 10:08 PM · Restricted Project
abrachet added a comment to D66063: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 5].

I've been trying and failing to come up with a good solution to the design. I only see three options:

  1. Adding the getHeader function as this patch does and accepting some fragility. In practice, usages within LLVM are probably fine, because we'll have testing, but it might not work as well for those who wish to use the library in their own tools.
  2. Using private inheritance or making the ELFObjectFile a private member of MutableELFObject instead of a base class. This would require MutableELFObject to opt in into functions that we know to be safe to use, and wouldn't allow usage of other functions. This is safer, but could result in a fair amount of extra code. This might need to be combined with 1) too to fix the specific issues this patch addresses.
  3. Something more radical involving bigger changes in ELFObjectFile to prevent accessing the wrong header within the base class. I don't have anything specific in mind here at the moment.

    Does anybody else have any thoughts on this?
Aug 20 2019, 9:24 PM · Restricted Project
abrachet updated the diff for D66063: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 5].

Addressed comments

Aug 20 2019, 9:24 PM · Restricted Project
abrachet updated the diff for D66062: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 4].

Addressed comments. Made unit tests better.

Aug 20 2019, 8:24 PM · Restricted Project
abrachet added a comment to D65633: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 3].

I've been using ::testing::ElementsAre(...) against a vector of StringRef a lot, when it fails the output is really bad. Like this: element #1 is equal to { '.' (46, 0x2E), 's' (115, 0x73), 'e' (101, 0x65), 'c' (99, 0x63), '0' (48, 0x30) }, Is there a way to provide formatting for types to gtest? Or should I just be using const char *?

Aug 20 2019, 7:21 PM · Restricted Project
abrachet updated the diff for D65633: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 3].

Addressed comments

Aug 20 2019, 7:18 PM · Restricted Project
abrachet updated the diff for D65367: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 2].

Addressed review comments

Aug 20 2019, 6:19 PM · Restricted Project
abrachet added inline comments to D65367: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 2].
Aug 20 2019, 6:19 PM · Restricted Project
abrachet updated the diff for D64281: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 1].

Removed superfluous overloads from this patch not later ones

Aug 20 2019, 6:11 PM · Restricted Project
abrachet updated the diff for D64281: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 1].

Use size_t for indexes not uint64_t

Aug 20 2019, 6:01 PM · Restricted Project
abrachet added a comment to D64281: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 1].

FYI, you'll have to rebase this whole patch series after rL368826 due to Section::getName() changing signature

Aug 20 2019, 3:06 PM · Restricted Project
abrachet updated the diff for D64281: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 1].

Addressed review comments

Aug 20 2019, 3:01 PM · Restricted Project

Aug 19 2019

abrachet updated the diff for D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6].

Addressed comments

Aug 19 2019, 9:03 PM · Restricted Project
abrachet added a comment to D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6].

Ahh sorry about all those unrelated changes! Not sure what happened there probably a bad rebase like you said.

Aug 19 2019, 9:03 PM · Restricted Project
abrachet added reviewers for D66063: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 5]: grimar, MaskRay, pcc.
Aug 19 2019, 8:04 PM · Restricted Project
abrachet added a comment to D66063: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 5].

I'm concerned with the getHeader() call changes in ELFObjectFile, mostly because again it's introducing a very obvious point of failure. What if somebody added a new piece of functionality to the base class to get another piece of data from the header? There's a good change they'll call EF.getHeader(). Say the new function is called getFoo(): if another user then decides they want to call getFoo() on a MutableELFObject, then they'll end up using the unmodified header rather than the modified one, which could cause surprising bugs. I don't have an obvious answer to this, but I'm beginning to wonder if we should be using a different style of inheritance, one that only makes the functions available that we know to be safe from a MutableELFObject's point of view. This might be something like private inheritance. I'm not sure though, as it would mean providing shim functions to re-publicise the "safe" functions we care about. What are your thoughts?

Aug 19 2019, 8:04 PM · Restricted Project
abrachet updated the diff for D66063: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 5].

Change getHeader() to return a reference not pointer.

Aug 19 2019, 8:04 PM · Restricted Project
abrachet updated the diff for D66062: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 4].

rebase

Aug 19 2019, 6:55 PM · Restricted Project
abrachet added inline comments to D65633: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 3].
Aug 19 2019, 6:34 PM · Restricted Project
abrachet updated the diff for D65633: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 3].

Addressed review comments.

Aug 19 2019, 6:15 PM · Restricted Project

Aug 18 2019

abrachet added inline comments to D66403: Create MutableObjectWriter class.
Aug 18 2019, 8:39 PM · Restricted Project
abrachet created D66403: Create MutableObjectWriter class.
Aug 18 2019, 4:02 PM · Restricted Project

Aug 16 2019

abrachet added inline comments to D65633: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 3].
Aug 16 2019, 7:12 PM · Restricted Project
abrachet updated the diff for D65633: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 3].

Addressed review comments

Aug 16 2019, 7:09 PM · Restricted Project

Aug 15 2019

abrachet updated the diff for D66062: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 4].

Fixed failing test for std::distance call.

Aug 15 2019, 8:28 PM · Restricted Project
abrachet updated the diff for D66063: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 5].

Made a virtual getHeader method in ELFObjectFile

Aug 15 2019, 8:19 PM · Restricted Project
abrachet updated the diff for D66062: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 4].

Addressed review comments

Aug 15 2019, 6:54 PM · Restricted Project
abrachet added inline comments to D65633: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 3].
Aug 15 2019, 9:52 AM · Restricted Project
abrachet updated the diff for D65633: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 3].

Addressed review comments

Aug 15 2019, 9:44 AM · Restricted Project
abrachet added inline comments to D65367: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 2].
Aug 15 2019, 9:30 AM · Restricted Project
abrachet updated the diff for D65367: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 2].

Addressed comments

Aug 15 2019, 9:30 AM · Restricted Project

Aug 14 2019

abrachet added inline comments to D66062: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 4].
Aug 14 2019, 11:49 PM · Restricted Project
abrachet updated the diff for D66062: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 4].

Addressed review comments

Aug 14 2019, 11:44 PM · Restricted Project
abrachet added inline comments to D65633: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 3].
Aug 14 2019, 9:30 PM · Restricted Project
abrachet updated the diff for D65633: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 3].

Addressed review comments

Aug 14 2019, 9:25 PM · Restricted Project
abrachet updated the diff for D65367: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 2].

Addressed review comments

Aug 14 2019, 1:44 PM · Restricted Project

Aug 12 2019

abrachet updated the diff for D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6].

Rebase

Aug 12 2019, 11:28 PM · Restricted Project
abrachet updated the diff for D65633: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 3].

rebase

Aug 12 2019, 10:40 PM · Restricted Project
abrachet added inline comments to D65367: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 2].
Aug 12 2019, 9:04 PM · Restricted Project
abrachet updated the diff for D65367: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 2].

Addressed review comments

Aug 12 2019, 8:48 PM · Restricted Project
abrachet updated the diff for D64281: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 1].

Addressed review comments

Aug 12 2019, 4:32 PM · Restricted Project

Aug 11 2019

abrachet added a parent revision for D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6]: D66063: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 5].
Aug 11 2019, 11:11 PM · Restricted Project
abrachet added a child revision for D66063: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 5]: D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6].
Aug 11 2019, 11:11 PM · Restricted Project
abrachet created D66070: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 6].
Aug 11 2019, 11:11 PM · Restricted Project

Aug 10 2019

abrachet added a child revision for D66062: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 4]: D66063: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 5].
Aug 10 2019, 11:21 PM · Restricted Project
abrachet added a parent revision for D66063: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 5]: D66062: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 4].
Aug 10 2019, 11:21 PM · Restricted Project
abrachet created D66063: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 5].
Aug 10 2019, 11:21 PM · Restricted Project
abrachet added a child revision for D65633: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 3]: D66062: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 4].
Aug 10 2019, 11:11 PM · Restricted Project
abrachet added a parent revision for D66062: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 4]: D65633: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 3].
Aug 10 2019, 11:11 PM · Restricted Project
abrachet created D66062: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 4].
Aug 10 2019, 11:11 PM · Restricted Project
abrachet updated the diff for D65633: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 3].
Aug 10 2019, 12:00 AM · Restricted Project

Aug 9 2019

abrachet updated the diff for D65367: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 2].

Moved remove and add out of this patch

Aug 9 2019, 10:57 PM · Restricted Project
abrachet updated the diff for D64281: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 1].

Addressed review comments

Aug 9 2019, 9:24 PM · Restricted Project

Aug 8 2019

abrachet added inline comments to D64281: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 1].
Aug 8 2019, 11:33 PM · Restricted Project
abrachet updated the diff for D64281: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 1].

Addressed review comments

Aug 8 2019, 11:09 PM · Restricted Project
abrachet added a comment to D65367: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 2].

I don't think you want to be modifying the number of dynamic symbols at all. That would require you to make other changes to loadable code, which would impact addresses, and effectively require you to completely relink the program.

You may however still need to modify the contents of the existing dynamic symbols (specifically you may need to be able to update their section indexes).

Aug 8 2019, 10:45 PM · Restricted Project
abrachet updated the diff for D65367: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 2].

Remove removeDynSymbol from MutableELFObject

Aug 8 2019, 10:45 PM · Restricted Project