This is an archive of the discontinued LLVM Phabricator instance.

[Object] Create MutableObject class for doing Object Mutations [Part 2]
AbandonedPublic

Authored by abrachet on Jul 18 2019, 8:41 PM.

Details

Summary

Create section sub classes for ELF

Diff Detail

Event Timeline

abrachet created this revision.Jul 18 2019, 8:41 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 18 2019, 8:41 PM

It looks like in this patch, you haven't uploaded the diff versus D64281, it's versus trunk. As previously explained, I think it's important you do the diff versus the previous patch, so that it's obvious what this adds over the previous one.

I also don't think this is the right next step, or at least it's too much for one patch. I think a better thing to do would be to add only the bare minimum number of sections you need to be able to remove a section from a very basic ELF (e.g. one with just a .data section in with no symbols). In this case, you probably just need a string table section, so that you can update it's contents following the removal of sections. That would allow you to write unit tests that test some useful functionality. Subsequent patches can add proper handling of other section types, so that the ELF is not invalidated following removal of certain sections, but in the first instance, you don't need to handle everything.

abrachet abandoned this revision.Jul 21 2019, 8:51 PM
MaskRay added a subscriber: MaskRay.EditedJul 22 2019, 12:11 AM

If you have branches a, b, and c (a depends on master, b depends on a, c depends on b):

# after syncing master, a, b and c became stale.
git rebase --onto master 'a^' a
  arc diff 'HEAD^'  # create/update a revision based on the diff master..a
git rebase --onto a 'b^' b  # this also switches to b
  arc diff 'HEAD^'  # create/update a revision based on the diff a..b     master..a is not included in the revision.
git rebase --onto b 'c^' c  # this also switches to b
  arc diff 'HEAD^'  # create/update a revision based on the diff b..c

Perhaps there is a better way to do things but this is how I handle dependent revisions.

In D64281, I still want to see how you are going to use MutableRange. Do you have a design what the end result will be?

If you have branches a, b, and c (a depends on master, b depends on a, c depends on b):

# after syncing master, a, b and c became stale.
git rebase --onto master 'a^' a
  arc diff 'HEAD^'  # create/update a revision based on the diff master..a
git rebase --onto a 'b^' b  # this also switches to b
  arc diff 'HEAD^'  # create/update a revision based on the diff a..b     master..a is not included in the revision.
git rebase --onto b 'c^' c  # this also switches to b
  arc diff 'HEAD^'  # create/update a revision based on the diff b..c

Perhaps there is a better way to do things but this is how I handle dependent revisions.

In D64281, I still want to see how you are going to use MutableRange. Do you have a design what the end result will be?

Thanks @MaskRay, thats very helpful I was having a hard time managing this.

I ended up just abandoning this revision for now because D64281 has changed so drastically and I wasn't ready for a part 2 to that yet so I didn't want this one to just be dangling here. That revision still uses a data structure called MutableRange, but it has changed a lot. I'll work on trying to improve the performance of batch operations on it in a bit. But I've drastically changed my whole project so I have put that off for now.