Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001114
--- Comment #18 from John Dallaway <[email protected]> 2011-02-01 11:51:49 GMT --- (In reply to comment #17) > (In reply to comment #16) > > Now since all system-wide blocking bugs are resolved I am going to check-out > > from CVS and produce patch(es) with remaining issues. > > > > It will include a patch on cortex.ld (comment #5). I could attach the diff > > here or open a new bug. > > > > Please advise. > > Mine: I would open new bug as it is architecture specific issue, and, perhaps, > it needs in a more wide discussion, ... However, there are many valuable > points > by the subject in this (Bug #1001114) report. > > John, What is your opinion? Looking at Ilija's latest mlt_cortexm_lpc17xx_inc.ldi, I am OK with a generic section macro being added to cortex.ld but without the _type_ parameter: #define SECTION_user(_name_, _region_, _vma_, _lma_) I think it is clear that this would be sufficiently generic for cortex.ld and potentially useful in other contexts. I like the idea that this macro will automatically define __*_start and __*_end symbols. My personal preference would be to name this "SECTION_user" rather than "SECTION_usr", but it's a minor point. I think I would prefer to see the ahb_bss section set up using the SECTION_user() macro rather than having a separate macro. The HAL author would take responsibility for zeroing the data (if appropriate) by defining a macro such as SECTION_CLEAR() or by some other means. I would vote for adding "SECTION_user(_name_, _region_, _vma_, _lma_)" in cortex.ld and elimination of the file mlt_cortexm_lpc17xx_inc.ldi. -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
