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

Repository
rL LLVM

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 ↗(On Diff #201888)

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 ↗(On Diff #201888)

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

41–42 ↗(On Diff #201888)

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 ↗(On Diff #201888)

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

122 ↗(On Diff #201888)

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 ↗(On Diff #201888)

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 ↗(On Diff #201888)

@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
1 ↗(On Diff #204001)

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.

23 ↗(On Diff #204001)

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.

192 ↗(On Diff #204001)

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

@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?