Fix courgette ELF x86 dissembler

Fix courgette ELF x86 dissembler

Courgette cannot parse files that have out of order NOBITS sections and instead
will crash. The solution to this is to skip them and encode them as raw bytes.

Also, courgette has a bug where it incorrectly emits ElfRelocationInstruction
instructions even when there are no valid R_386_RELATIVE relocations in the
file.

Added a test file that exhibits both of these symptoms.

BUG=424820, 423925
TEST=courgette_unittests
R=dgarrett@chromium.org, tommi@chromium.org

Committed: https://chromium.googlesource.com/chromium/src/+/3e6fa973958cb37622aa882f2c13b6927228e4fc

[Will Harris, 2014-10-18 01:19:26]

wfh@chromium.org changed reviewers:
+ dgarrett@chromium.org, tommi@chromium.org

[tommi (sloooow) - chröme, 2014-10-20 16:10:16]

I don't have a way to verify that this is correct thing to do unfortunately but
this lgtm.

[dgarrett, 2014-10-20 18:11:51]

On 2014/10/20 16:10:16, tommi wrote:
> I don't have a way to verify that this is correct thing to do unfortunately
but
> this lgtm.

The ELF spec allows a lot of variety. I did a lot of the initial support by just
seeing what sample ELF files did and assuming it was semi-universal. While it's
generally held up better than I was first expecting, this bug doesn't surprise
me.

[dgarrett, 2014-10-20 18:15:44]

lgtm

https://codereview.chromium.org/664803002/diff/20001/courgette/disassembler_e...
File courgette/disassembler_elf_32.cc (right):

https://codereview.chromium.org/664803002/diff/20001/courgette/disassembler_e...
courgette/disassembler_elf_32.cc:265: if (section_header->sh_type == SHT_NOBITS)
This seems like the right thing to do... I'm surprised the original code was
working.

Did I have no NOBITS sections in the files it worked with?

There was substantial testing using a wide variety of binaries, but I have no
memory of how common NOBITS sections are.

[dgarrett, 2014-10-20 18:15:46]

lgtm

[Will Harris, 2014-10-20 19:01:44]

https://codereview.chromium.org/664803002/diff/20001/courgette/disassembler_e...
File courgette/disassembler_elf_32.cc (right):

https://codereview.chromium.org/664803002/diff/20001/courgette/disassembler_e...
courgette/disassembler_elf_32.cc:265: if (section_header->sh_type == SHT_NOBITS)
On 2014/10/20 18:15:44, dgarrett wrote:
> This seems like the right thing to do... I'm surprised the original code was
> working.
> 
> Did I have no NOBITS sections in the files it worked with?
> 
> There was substantial testing using a wide variety of binaries, but I have no
> memory of how common NOBITS sections are.

NOBITS are in almost every ELF file as the .bss is always NOBITS as it's just
going to be some memory that the dynamic linker will zero out with enough space
for the globals.

In all the files I can compile, the .bss is near the end of the file (typically
before the comment or debug section) but the next section is either at the same
file offset or higher, which means the bug won't trigger.

e.g. a file I compile just now has

[24] .data             PROGBITS        0804a00c 00100c 000008 00  WA  0   0  4
[25] .bss              NOBITS          0804a014 001014 000008 00  WA  0   0  4
[26] .comment          PROGBITS        00000000 001014 00002a 01  MS  0   0  1

The issue with the ARC files was that I think they were manually shifting the
.bss beyond the end of the file, perhaps they are using a custom linker script
for this?  There is more info in the bug on why this causes a segfault.  I can't
find the makefile for libdvm.so to check what's special about it.

[dgarrett, 2015-03-02 18:25:08]

My LGTM is still valid here.

[Will Harris, 2015-03-02 18:53:46]

On 2015/03/02 18:25:08, dgarrett wrote:
> My LGTM is still valid here.

Thanks, now that we have the okay to break backwards compat, I'm gradually
resurrecting and rebasing and re-testing all these CLs and will finish the rest
this week.

[Will Harris, 2015-03-02 19:31:24]

The CQ bit was checked by wfh@chromium.org

[Will Harris, 2015-03-02 19:31:24]

The patchset sent to the CQ was uploaded after l-g-t-m from
dgarrett@chromium.org, tommi@chromium.org
Link to the patchset: https://codereview.chromium.org/664803002/#ps40001 (title:
"rebase")

[commit-bot: I haz the power, 2015-03-02 19:32:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/664803002/40001

[commit-bot: I haz the power, 2015-03-02 20:02:35]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-03-02 20:02:36]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Will Harris, 2015-03-02 21:05:12]

On 2015/03/02 20:02:36, I haz the power (commit-bot) wrote:
> Try jobs failed on following builders:
>   chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

"new file mode 100755" in the patch

this is is correct so I'm going to just git cl land this. Seems to be a
recurring bug with the CQ.

[commit-bot: I haz the power, 2015-03-02 21:16:56]

Patchset 4 (id:??) landed as
https://crrev.com/3e6fa973958cb37622aa882f2c13b6927228e4fc
Cr-Commit-Position: refs/heads/master@{#318764}

[Will Harris, 2015-03-02 21:17:06]

Committed patchset #4 (id:60001) manually as
3e6fa973958cb37622aa882f2c13b6927228e4fc (presubmit successful).