ELf2Hex

1,217 views
Skip to first unread message

John Leidel

unread,
Jul 10, 2016, 7:48:41 PM7/10/16
to RISC-V SW Dev
All, has anyone else experienced recent issues with the elf2hex built by default using the riscv-tools build?  I was originally trying to get a binary blob dumped into a Rocket test using some custom startup code (and startup addresses), but elf2hex failed to dump the hex.  I scaled back to a simple example: 

$RISCV/bin/riscv64-unknown-elf-gcc -o hello.exe hello.c
$RISCV/bin/riscv64-unknown-elf-objdump --disassemble-all --disassemble-zeroes --section=.text --section=.text.startup --section=.data hello.exe > hello.dis

The hello.dis output appears to be perfectly valid

$RISCV/bin/elf2hex 16 32768 hello.dis > hello.hex

elf2hex: ../fesvr/elfloader.cc:29: std::map<std::__cxx11::basic_string<char>, long unsigned int> load_elf(const char*, memif_t*): Assertion `IS_ELF32(*eh64) || IS_ELF64(*eh64)' failed.

The elf2hex clearly asserts, but the binary is valid: 
hello.exe:     file format elf64-littleriscv
I also runs in Spike without any issues.  

Any thoughts?

Michael Clark

unread,
Jul 10, 2016, 8:36:54 PM7/10/16
to John Leidel, RISC-V SW Dev
Random question. What is the host system? Is it big endian or little endian? ppc64?

There are fewer big endian systems around these days however they do exist. I just thought I would ask as I suspect the fesvr code would fail if the host is a big endian as I can’t see any bswaps.

Unfortunately I can’t test any of the host/target loader stuff as I have a KC705 which requires an untethered rocket.

The current code looks like it should work on little endian. When did it break?

John Leidel

unread,
Jul 10, 2016, 8:43:20 PM7/10/16
to Michael Clark, RISC-V SW Dev
Michael, its little endian (x86_64). Strangely enough, Spike has no issues with the same binary.

-- John D. Leidel

Michael Clark

unread,
Jul 10, 2016, 8:57:36 PM7/10/16
to John Leidel, RISC-V SW Dev
Hi John,

Those assertion tests should work fine on little endian.

e_ident is not even within the portion of the Ehdr struct that differs between ELF32 and ELF64. 1, 2 are the correct values for ELFCLASS32 and ELFCLASS64 and EI_CLASS is 4. it appears from the code that it should work.

#define IS_ELF32(hdr) (IS_ELF(hdr) && (hdr).e_ident[4] == 1)
#define IS_ELF64(hdr) (IS_ELF(hdr) && (hdr).e_ident[4] == 2)

The file is open and the mmap has succeeded otherwise the previous assert would have failed. i.e. stepping though the statements leading up to the failed assertion.

std::map<std::string, uint64_t> load_elf(const char* fn, memif_t* memif)
{
  int fd = open(fn, O_RDONLY);
  struct stat s;
  assert(fd != -1);
  if (fstat(fd, &s) < 0)
    abort();
  size_t size = s.st_size;

  char* buf = (char*)mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
  assert(buf != MAP_FAILED);
  close(fd);

  assert(size >= sizeof(Elf64_Ehdr));
  const Elf64_Ehdr* eh64 = (const Elf64_Ehdr*)buf;
  assert(IS_ELF32(*eh64) || IS_ELF64(*eh64));

I wonder if it is something in hello.c. Can you pastebin the file and I can test locally?

Oh, you passing the .dis file into elf2hex, not the ELF file itself? I just noticed.

Michael.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/4C20A693-A2A7-4ABF-8FB3-B6DA91372653%40gmail.com.

signature.asc

John Leidel

unread,
Jul 10, 2016, 9:03:55 PM7/10/16
to Michael Clark, RISC-V SW Dev
Michael, I arrived at the same conclusion.  My tool chain build is about a month old, so i went back and looked at trunk. The assert still exists.  

I'll setup a place where you can grab the files and test.

Cheers
John

-- John D. Leidel 

John Leidel

unread,
Jul 10, 2016, 10:18:17 PM7/10/16
to Michael Clark, RISC-V SW Dev
Michael (et.al.), this was entirely user error... 
elf2hex < binary, not *dis... 

The binary dumps fine now that I used it rather than the hex.  PEBKAC

Michael Clark

unread,
Jul 10, 2016, 10:32:21 PM7/10/16
to John Leidel, RISC-V SW Dev
That’s good you have it working now. Same thing happens to me often.

Quite often the more obvious the issue, the harder it is to find. Human nature.

Shraddha Devaiya

unread,
Sep 1, 2020, 8:32:36 AM9/1/20
to RISC-V SW Dev, Michael Clark, RISC-V SW Dev, john.leidel
Hi,
I ran into the same issue as @john.leidel mentioned in the beginning. Can you please suggest the solution for this error :
elf2hex: ../fesvr/elfloader.cc:36: std::map<std::__cxx11::basic_string<char>, long unsigned int> load_elf(const char*, memif_t*, reg_t*): Assertion `IS_ELF_RISCV(*eh64) || IS_ELF_EM_NONE(*eh64)' failed.

I couldn't understand from this conversation.What can I do for this?

Thanks & Regards,
Shraddha Devaiya.

Reply all
Reply to author
Forward
0 new messages