Bug 452321 - AT_ranges attribute might get relocated
Summary: AT_ranges attribute might get relocated
Status: RESOLVED FIXED
Alias: None
Product: TCF
Classification: Tools
Component: Agent (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 major (vote)
Target Milestone: 1.3   Edit
Assignee: Project Inbox CLA
QA Contact: Eugene Tarassov CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-19 11:58 EST by xavier pouyollon CLA
Modified: 2015-06-16 03:17 EDT (History)
0 users

See Also:


Attachments
ICC built DKM. (138.91 KB, application/octet-stream)
2014-11-19 11:58 EST, xavier pouyollon CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description xavier pouyollon CLA 2014-11-19 11:58:53 EST
Created attachment 248762 [details]
ICC built DKM.

Hi Eugene,

Using this VxWorks DKM built with ICC 64 bits, I can not have return to source code for address ....874.

 <0><108e>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <108f>   DW_AT_comp_dir    : (indirect string, offset: 0xe41): /home/xavier/Datas/installs/vx20141114024242_fr51-ostools_fr51-ostools/workbench-4/workspace/cpp_demo/VxSim64vsb_SIMLINUXicc_LP64_LARGE_SMP
    <1093>   DW_AT_language    : 4      (C++)
    <1094>   DW_AT_name        : (indirect string, offset: 0xecd): /home/xavier/Datas/installs/vx20141114024242_fr51-ostools_fr51-ostools/workbench-4/workspace/cpp_demo/main.cpp
    <1098>   DW_AT_producer    : (indirect string, offset: 0xf3c): Intel(R) C Compiler for Intel(R) 64 applications running on VxWorks* 7, Version 14.0 Build 20140219

    <109c>   DW_AT_low_pc      : 0x0
    <10a4>   DW_AT_ranges      : 0x60   <=== Get relocated

00000000000010a4 R_X86_64_32       .debug_ranges+0x0000000000000060

Proposed patch : https://git.eclipse.org/r/#/c/36707/

Note that it does NOT solve the return to source. There is something else to understand; The file doesn't look that good (see how many sections it has !). However, by looking at .debug_ranges, for ....874, I find AT_ranges to be 0x60, then it should find the right compilation unit aka 108e but instead, it finds 0xA6F. Still looking into this.)
Comment 1 Eugene Tarassov CLA 2014-11-19 14:37:55 EST
The patch looks good, I have committed it.
Comment 2 Eugene Tarassov CLA 2015-03-11 15:21:58 EDT
Submitted with Gerrit