Bug 387816 - TCF ELF symbol reader does not correctly handle labels in assembly source code
Summary: TCF ELF symbol reader does not correctly handle labels in assembly source code
Status: RESOLVED FIXED
Alias: None
Product: TCF
Classification: Tools
Component: Agent (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 1.1   Edit
Assignee: Project Inbox CLA
QA Contact: Eugene Tarassov CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-22 13:53 EDT by Didier Brachet CLA
Modified: 2013-06-05 04:40 EDT (History)
0 users

See Also:


Attachments
proposed patch (1.28 KB, patch)
2012-08-23 12:01 EDT, Didier Brachet CLA
no flags Details | Diff
Proposed patch (1.31 KB, patch)
2012-08-24 10:44 EDT, Didier Brachet CLA
mober.at+eclipse: iplog-
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Didier Brachet CLA 2012-08-22 13:53:14 EDT
Build Identifier: 

If your application is built from assembly source code; the TCF agent ELF symbol reader can have issues dealing with labels people may have added in their code. Depending on the compiler those labels can be either defined with a type NOTYPE or FUNCTION in the ELF file but always have a size of 0. If the type is FUNCTION, then the find_by_addr_in_sym_tables() will fail to find any symbol for any assembly function address that is located after a label. This is because elf_find_symbol_by_address() will return the symbols representing a label with type FUNCTION but size 0 and this will cause the following test to fail:

 if (sym_addr + sym_info.size > lt_addr) {
...

One fix for this would be to also test if the sym_info.size is equal to 0 and, in this case, always return this symbol without checking the address range. 

The advantage of this solution is that it will allow seeing all the labels in the assembly view if they are marked as FUNCTION. The problem is that we will potentially not return the function address but instead a label address but is this really an issue?

Note that the native gcc compiler on my Linux box does mark the label type as NOTYPE so we do not see the problem but I can reproduce this on other architectures (maybe it is a matter of compiler flags?).

Reproducible: Always




We should also potentially have to handle the case where the function size is not defined in the assembly file (which seems to be often the case). In this case, we end up with a function symbol of size 0 (similar to a label). The fix described previously would also solve this problem.
Comment 1 Didier Brachet CLA 2012-08-23 12:01:41 EDT
Created attachment 220205 [details]
proposed patch

I am not convinced this patch is the best way to fix this but at least it gives an idea of what we need.
Comment 2 Didier Brachet CLA 2012-08-24 10:44:18 EDT
Created attachment 220272 [details]
Proposed patch
Comment 3 Eugene Tarassov CLA 2012-08-24 14:18:21 EDT
Basically, if function size is not defined, the patch assumes the function ends at next function symbol. I think it is correct assumption.
I have committed the patch.
Thanks!
Comment 4 Martin Oberhuber CLA 2013-05-24 11:36:13 EDT
Comment on attachment 220272 [details]
Proposed patch

iplog- since author is in git:

http://git.eclipse.org/c/tcf/org.eclipse.tcf.agent.git/commit?id=e8950e7e2225dcd931e51ae46975d011e350b47a