dump_syms crashes when used on a binary compiled for mips32 bigendian

[vishal sharma]

Hello,

I've got an issue where dump_syms utility is compiled on x86 is used to dump symbols from a binary compiled for mips32 bigendian architecture. The binary is compiled using gcc version 4.2.0 and GNU ld version 2.17.

The back trace in gdb shows it is breaking in:

void google_breakpad::(anonymous namespace)::FindElfClassSection<google_breakpad::ElfClass32>(char const*, char const*, google_breakpad::ElfClass32::Word, void const**, int*) ()

Any insight is greatly appreciated.

Thanks,
Vishal

[Ted Mielczarek]

This is probably just a bug in the symbol dumping code, maybe related to the target binary being a different endianness? If you can provide a full stack trace (or even better, a binary that I can run dump_syms on that reproduces the problem) we can likely figure it out.

 

-Ted

 

 

[vishal sharma]

Hi Ted,

Sure, here is the stack trace.

#0  0x0807302b in FindElfClassSegment<google_breakpad::ElfClass32> (segment_size=0xbfb05488, segment_start=0xbfb05484, segment_type=4, elf_base=0xaf9b4000 "\177ELF\001\002\001") at ../src/common/linux/elfutils.cc:99
#1  google_breakpad::FindElfSegment (elf_mapped_base=0xaf9b4000, segment_type=4, segment_start=0xbfb05484, segment_size=0xbfb05488, elfclass=0xbfb0548c) at ../src/common/linux/elfutils.cc:183
#2  0x080734a6 in FindElfBuildIDNote (identifier=0xbfb055ac "", elf_mapped_base=0xaf9b4000) at ../src/common/linux/file_id.cc:98
#3  google_breakpad::FileID::ElfFileIdentifierFromMappedFile (base=0xaf9b4000, identifier=0xbfb055ac "") at ../src/common/linux/file_id.cc:144
#4  0x08070d96 in ReadSymbolDataElfClass<google_breakpad::ElfClass32> (out_module=0xbfb0563c, options=..., debug_dirs=..., obj_filename=..., elf_header=0xaf9b4000) at ../src/common/linux/dump_symbols.cc:815
#5  google_breakpad::ReadSymbolDataInternal (obj_file=0xaf9b4000 "\177ELF\001\002\001", obj_filename=..., debug_dirs=..., options=..., module=0xbfb0563c) at ../src/common/linux/dump_symbols.cc:909
#6  0x08071e2f in google_breakpad::ReadSymbolData (obj_file=..., debug_dirs=..., options=..., module=0xbfb0563c) at ../src/common/linux/dump_symbols.cc:943
#7  0x08071ec0 in google_breakpad::WriteSymbolFile (obj_file=..., debug_dirs=..., options=..., sym_stream=...) at ../src/common/linux/dump_symbols.cc:925
#8  0x0804b532 in main (argc=2, argv=0xbfb05744) at ../src/tools/linux/dump_syms/dump_syms.cc:82


If I comment the FindElfBuildIDNote knowing that this linker does not support build-id then it crashes in FindElfClassSection when trying to calculate the hash using the text section.


#0  0x0808bd9b in void google_breakpad::(anonymous namespace)::FindElfClassSection<google_breakpad::ElfClass32>(char const*, char const*, google_breakpad::ElfClass32::Word, void const**, int*) ()
#1  0x0808c045 in google_breakpad::FindElfSection(void const*, char const*, unsigned int, void const**, int*, int*) ()
#2  0x0808c4ad in google_breakpad::HashElfTextSection(void const*, unsigned char*) ()
#3  0x0808c60c in google_breakpad::FileID::ElfFileIdentifierFromMappedFile(void const*, unsigned char*) ()
#4  0x080876cb in bool (anonymous namespace)::ReadSymbolDataElfClass<google_breakpad::ElfClass32>(google_breakpad::ElfClass32::Ehdr const*, std::string const&, std::vector<std::string, std::allocator<std::string> > const&, google_breakpad::DumpOptions const&, google_breakpad::Module**) ()
#5  0x08087f35 in google_breakpad::ReadSymbolDataInternal(unsigned char const*, std::string const&, std::vector<std::string, std::allocator<std::string> > const&, google_breakpad::DumpOptions const&, google_breakpad::Module**) ()
#6  0x0808804e in google_breakpad::ReadSymbolData(std::string const&, std::vector<std::string, std::allocator<std::string> > const&, google_breakpad::DumpOptions const&, google_breakpad::Module**) ()
#7  0x080880e0 in google_breakpad::WriteSymbolFile(std::string const&, std::vector<std::string, std::allocator<std::string> > const&, google_breakpad::DumpOptions const&, std::ostream&) ()
#8  0x0808d967 in main ()


The hello world binary for this exercise compiled as a target is attached.

Target gcc version is 4.2.0 and ld version is 2.17

Thanks for your help!

Vishal

[vishal sharma]

Hi Ted,

It looks like the use of reinterpret_cast is an issue here. The ehdr and shdr structure variables are not loaded based on the endian flag value from the header. That seem to cause issues with all offsets and sizes.

Thought I share this quick note with you as a data point for when you may get a chance to review the code.

Thanks,
Vishal

[Ted Mielczarek]

Hi Vishal,

 

You're right in that the code as written doesn't handle endianness differences. I started looking at it and fixing that is somewhat invasive. I don't have any need for things to work on MIPS, so I'm not likely to do all the work, but I did spend a few minutes sketching out the beginning of a patch that you can start from:

http://hg.mozilla.org/users/tmielczarek_mozilla.com/breakpad-mq/raw-file/2828e85a8512/elfutils-endianness

 

It adds an additional template parameter to the functions that were already parameterized on word size. To finish that off you'd have to make sure that anything that's touching ELF structures is templatized with an ElfData parameter, and every read of a value from a struct is wrapped with ElfData::swap. It's probably a bit tedious but straightforward.

 

Let me know if you have any questions,

-Ted

--

You received this message because you are subscribed to the Google Groups "google-breakpad-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-breakpad-d...@googlegroups.com.

To post to this group, send email to google-brea...@googlegroups.com.

Visit this group at http://groups.google.com/group/google-breakpad-discuss.

For more options, visit https://groups.google.com/d/optout.

 

[vishal sharma]

Hi Ted,

So I figured, after my last post as I got a chance to read a little more through the code. After that I created a small utility function in a utility type class and began punching a call to swap the bytes. By Friday evening I got it to successfully extract the symbols and put in a file and it does look good so far.

Once I get a chance to verify the extract as I play more with an actual crash off the device and use stackwalker etc., I will propose this as a patch and submit the changes.

It wasn't too tricky once I figured how the code was written already and as I understood the structure better (readelf and bless utilities helped)

Thanks,
Vishal

To unsubscribe from this group and stop receiving emails from it, send an email to google-breakpad-discuss+unsub...@googlegroups.com.

[Bryan Green]

Hi,

I am encountering this same stack trace when running dump_syms on an ARMEB (big endian arm) binary.
I am wondering, has any progress been made on this issue since the last post?  Perhaps I can help if either of you have a new patch to share.

Thanks,
Bryan

[arunc]

Hi Vishal, 

I'm also facing the same issue with MIPS,

My Issue : https://groups.google.com/g/google-breakpad-discuss/c/kO0SJ0E2L8Y/m/81k_sq69BgAJ

Could you please help me to share the patch that worked for you, I will give a try with that

Thanks.

Arun