This is an archive of the discontinued LLVM Phabricator instance.

[llvm-objcopy] Implement IHEX reader
ClosedPublic

Authored by evgeny777 on May 29 2019, 6:12 AM.

Diff Detail

Event Timeline

evgeny777 created this revision.May 29 2019, 6:12 AM
rupprecht added inline comments.Jun 6 2019, 11:40 AM
test/tools/llvm-objcopy/ELF/ihex-reader.test
4

The output format here is unspecified, so it's not clear if we should convert this to elf32-i386, elf64-x86-64, any of the (unimplemented) macho/coff outputs, etc. We should either assume the output is also ihex (what GNU objcopy appears to do) or return some kind of warning/error (also seems reasonable if we don't need to match failure-ness for that situation -- I wonder if anyone relies on that working?)

I'm not sure if this problem is related to your patch though; running "llvm-objcopy -I binary -Barm foo.txt bar" also creates an object file when it shouldn't. For now, can you just put an explicit output format (probably you want -O elf64-x86-64)

22

(same for all the other places, e.g. here too)

41–42

You should be able to avoid intermediate files by piping directly into objcopy, e.g.
echo "01000000FF" | not llvm-objcopy -I ihex - %t-none 2>&1 | FileCheck %s --check-prefix=BAD_LENGTH

99

nit: remove the indices (i.e. (35) here) since they're irrelevant to the test

122

Running the same scenario through GNU objcopy, there are a couple significant differences in the generated object file starting here -- looks like GNU objcopy gets confused and splits the "0123456789@" into separate sections, so size here is 8, and the next section is size 3 to handle the spill over... it looks like llvm-objcopy is correct here, but mind reviewing that to make sure llvm-objcopy is making sense here?

evgeny777 updated this revision to Diff 204001.Jun 11 2019, 3:04 AM
evgeny777 marked an inline comment as done.

Addressed review comments

test/tools/llvm-objcopy/ELF/ihex-reader.test
122

GNU objcopy always starts new section if it encounters SegmentAddr (02) or ExtendedAddr (04). There seems to be no strong reason doing so in llvm-objcopy, unless someone explicitly requests this.

rupprecht accepted this revision.Jun 12 2019, 3:27 PM
rupprecht marked an inline comment as done.
rupprecht added a subscriber: seiya.
rupprecht added inline comments.
test/tools/llvm-objcopy/ELF/ihex-reader.test
4

@seiya is working on patch to fix this, btw

This revision is now accepted and ready to land.Jun 12 2019, 3:27 PM
jhenderson added inline comments.Jun 13 2019, 2:20 AM
test/tools/llvm-objcopy/ELF/ihex-reader.test
2

Nit: missing trailing full stop here and below at the end of comments. Also, we've started using '##' in many new LLVM tools tests to clarify the difference between comments and actual test commands, so it would be good if you changed that.

24

Nit: don't mix single-dash long options with double-dash long options if you can avoid it (i.e. -section-headers -> --section-headers). Applies throughout this test.

193

I'd find it much easier to read this test, if the CHECKs for each individual case appear immediately after the indivdiual test case(s) using them, i.e:

# RUN: some stuff | FileCheck
# CHECK:

# RUN: some more stuff | FileCheck --check-prefix=CHUCK
# RUN: yet more stuff | FileCheck --check-prefix=CHUCK
# CHUCK:
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJun 13 2019, 2:53 AM

@jhenderson Sorry, I've already pushed it. I'll make a follow-up

RKSimon added inline comments.
llvm/trunk/tools/llvm-objcopy/ELF/Object.cpp
1201 ↗(On Diff #204459)

@evgeny777 https://pvs-studio.com/en/blog/posts/cpp/0771/ is warning that the SecNo++ isn't guaranteed to be evaluated in the correct order - maybe perform the increment afterward?