From: SourceForge.net <no...@so...> - 2008-09-13 10:36:41
|
Bugs item #2108799, was opened at 2008-09-13 12:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2108799&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: linker Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ondrej Petr (ondrej_petr) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong OFFSET generated in AOMF51 file for automatic vars Initial Comment: I use SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.8.0 #5117 (Mar 23 2008) (MINGW32) with Silicon Laboratories IDE version 3.41 that takes debugging info from OMF file. There are 3 problems: 1. Automatic variables and parameters are indicated with WRONG OFFSET value (0x00FF for all of such vars) in AOMF file. The consequence are heavy problems in debugging - watches of such vars show values from wrong address and I must guess correct address from disassebled code as such vars are NOT referenced even in .map file(!). 2. When compiled as reentrant, auto and parameter vars still appear in the list and have the same OFFSET of 0x00FF. I expect, that in that case these variables are places on stack and have no absolute address. Similarly, I expect that it is not possible to extract information to calculate current address of on-stack var. If this is true, it is better not to put records of such vars to AOMF file rather then present it with wrong address. 3. Symbols are presented in upper case in AOMF file, what is not comfortable and can cause potential problem with C case sensitivity. I had a look in OMF file to problematic records and realize that Silicon Labs IDE shows exactly what it see in OMF. I have no access to exact parameters used to call linker, I know only that c:\Program files\SDCC\BIN\SDCC.EXE is called and "--debug --use-stdout -V" is probably included in command line parameters. Best regards, Ondrej ond...@ri... ond...@re... P.S. SDCC 2.6.0 behaves same. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2108799&group_id=599 |