Bug 432431 - is_p_header_region() is too strict and return 0 if segment file_size == 0
Summary: is_p_header_region() is too strict and return 0 if segment file_size == 0
Status: NEW
Alias: None
Product: TCF
Classification: Tools
Component: Agent (show other bugs)
Version: 1.2   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Eugene Tarassov CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-09 09:30 EDT by Christophe Augier CLA
Modified: 2014-06-19 12:36 EDT (History)
0 users

See Also:

Attachments
Correct file (10.59 KB, application/octet-stream)
2014-06-19 12:33 EDT, Christophe Augier CLA 		no flags Details
File showing issue (10.59 KB, application/octet-stream)
2014-06-19 12:36 EDT, Christophe Augier CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Christophe Augier CLA 2014-04-09 09:30:57 EDT 
Hi,

I encountered ELF files which show a loadable segment file_size equal to zero but an higher mem_size.

Anyway the function is_p_header_region in tcf_elf.c doesn't recognize these segments and consequently our TCF based debugger can't find the debug info (for resolving addresses to lines for instance.)

I don't think the ELF spec is very specific about that as it says file_size can be zero but not if it is only when the segment is empty.
Comment 1 Eugene Tarassov CLA 2014-04-14 14:07:54 EDT 
Could you send such ELF file that can be used to reproduce the issue?
Comment 2 Christophe Augier CLA 2014-06-19 12:33:40 EDT 
Created attachment 244358 [details]
Correct file

Attached correct version of file that works fine.
Comment 3 Christophe Augier CLA 2014-06-19 12:36:12 EDT 
Created attachment 244359 [details]
File showing issue

Attached version of file that shows the issue:

  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x0000000000000000 0x0000000000000764  R E    200000
instead of

  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x0000000000000764 0x0000000000000764  R E    200000

I manually edited a correct file but it looks like it correctly "simulates" the problem seen with our binary.