Well, the unwind code is being pulled in for: Unwind table index '.ARM.exidx' at offset 0xa3fb8 contains 1 entries: 0x9b300 <__divdi3>: 0x1 [cantunwind]
So back-tracking that may also help. Gedare On Tue, Aug 11, 2015 at 10:09 AM, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > > > On 8/11/2015 9:00 AM, Gedare Bloom wrote: >> >> On Tue, Aug 11, 2015 at 9:59 AM, Gedare Bloom <ged...@gwu.edu> wrote: >>> >>> Yeah until you or someone can figure out how to get the .ARM.exidx >>> section from being placed in the .bss, a quick work-around would be to >>> provide an alternate code to clear the bss that does something like... >>> >>> memset(bsp_section_bss_begin, 0, __exidx_start - bsp_section_bss_begin); >>> memset(__exidx_start, 0, bsp_section_bss_end); >>> >> Let me be clear, this is a hack but hopefully will get you past the >> exception. > > > I don't see any difference between the xilinx BSP and the raspberrypi > linkcmds. And it looks like the code for section copying/cleaning is > the same. > > Comparing the two for differences might yield something but I am not > seeing it quickly. :( > > >>> On Tue, Aug 11, 2015 at 9:32 AM, Rohini Kulkarni <krohini1...@gmail.com> >>> wrote: >>>> >>>> OK! So is there any immediate solution which can be tried? >>>> >>>> On Tue, Aug 11, 2015 at 6:32 PM, Gedare Bloom <ged...@gwu.edu> wrote: >>>>> >>>>> >>>>> I can see the following pertinent information: >>>>> [15] .bss NOBITS 001156e0 0a8fd8 00fab0 00 WA 0 >>>>> 0 32 >>>>> The bss section starts at 0x1156e0, has size 0xfab0, and is writeable. >>>>> >>>>> In the symbol table we can see: >>>>> >>>>> 7825: 001156e0 0 NOTYPE GLOBAL DEFAULT 15 >>>>> bsp_section_bss_begin >>>>> The bsp_section_bss_begin variable has value 0x1156e0, this is good. >>>>> >>>>> 8729: 0000fab0 0 NOTYPE GLOBAL DEFAULT ABS bsp_section_bss_size >>>>> The bsp_section_bss_size is 0xfab0, which is also good. >>>>> >>>>> Looking at the segments I see one possible oddity. Look at the first >>>>> and >>>>> last >>>>> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align >>>>> EXIDX 0x0a3fb8 0x001106b8 0x001106b8 0x00008 0x00008 R 0x4 >>>>> LOAD 0x093900 0x00100000 0x00100000 0x156d8 0x7efc000 RW >>>>> 0x20 >>>>> >>>>> The first one starts inside of the second! This could well be the >>>>> reason for your problem. The .ARM.exidx section is being define >>>>> read-only, and is being put into a segment that overlaps with the >>>>> segment that catches most of the RW memory. >>>>> >>>>> Gedare >>>>> >>>>> On Mon, Aug 10, 2015 at 4:23 PM, Rohini Kulkarni >>>>> <krohini1...@gmail.com> >>>>> wrote: >>>>>> >>>>>> I did a readelf on the rki elf. I have attached the file. Is this >>>>>> information helping in anyway? >>>>>> >>>>>> On Wed, Aug 5, 2015 at 9:16 PM, Gedare Bloom <ged...@gwu.edu> wrote: >>>>>>> >>>>>>> >>>>>>> In arm/shared/startup/linkcmds.base these barriers are used to add >>>>>>> gaps in the memory layout at link-time to accommodate for the size >>>>>>> requirements of the MMU. xbarrier aligns the executable region, >>>>>>> robarrier aligns the read-only memory, and rwbarrier aligns the >>>>>>> read-write memory. >>>>>>> >>>>>>> On Tue, Aug 4, 2015 at 6:23 PM, Rohini Kulkarni >>>>>>> <krohini1...@gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 5, 2015 at 1:47 AM, Gedare Bloom <ged...@gwu.edu> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Aug 4, 2015 at 2:18 PM, Rohini Kulkarni >>>>>>>>> <krohini1...@gmail.com> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Jul 28, 2015 at 5:51 AM, Pavel Pisa >>>>>>>>>> <ppisa4li...@pikron.com> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hello Rohini and Gedare, >>>>>>>>>>> >>>>>>>>>>> On Friday 24 of July 2015 15:33:03 Gedare Bloom wrote: >>>>>>>>>>>> >>>>>>>>>>>> What are the values of bsp_section_bss_begin, and >>>>>>>>>>>> bsp_section_bss_size? >>>>>>>>>>>> >>>>>>>>>>>> Apparently, the memset is trying to write into the .text (code) >>>>>>>>>>>> section, which is a very bad thing to do indeed. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Qiao Yang in RPi 1 BSP now works in the similar >>>>>>>>>>> area to enable right graphic memory mapping. >>>>>>>>>>> >>>>>>>>>>> So my guess is that there could be problem caused >>>>>>>>>>> by used MMU mode granularity, which is is 1 MB so >>>>>>>>>>> if RO and RW sections are present in the same 1MB >>>>>>>>>>> aligned block ten there can be problem. It depends >>>>>>>>>>> which section is filled the first. If data and then >>>>>>>>>>> text (RO) the troubles begin. If the order is vice >>>>>>>>>>> versa then some part of text can be RW instead of RO, >>>>>>>>>>> but it should work and cache should not be a problem. >>>>>>>>>>> >>>>>>>>>>> But I have not dig into this case too much. >>>>>>>>>>> Only short glimpse. >>>>>>>>>>> >>>>>>>>>>> One option is to define 1 MB alignment between text >>>>>>>>>>> ad data for RPi case. There is quite a lot of memory >>>>>>>>>>> when compared to most RTEMS embedded targets to the >>>>>>>>>>> waste is not so important. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I didn't quite get what this means. I have no clue on how to >>>>>>>>>> proceed >>>>>>>>>> with >>>>>>>>>> this. >>>>>>>>> >>>>>>>>> The MMU defines memory regions in 1MB chunks. Each chunk can have >>>>>>>>> its >>>>>>>>> own permissions (read-only, or read-write) set. If the .text and >>>>>>>>> .data >>>>>>>>> (or some other section) overlaps in the same 1MB chunk, and the >>>>>>>>> wrong >>>>>>>>> permission gets set, then there can be a problem e.g. part of .data >>>>>>>>> might be RO or part of .text might be RW. >>>>>>>>> >>>>>>>>> Did you try the code Sebastian posted? to change the robarrier to >>>>>>>>> rwbarrier? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> What exactly are these barriers? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Gedare >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best wishes, >>>>>>>>>>> >>>>>>>>>>> Pavel >>>>>>>>>>> >>>>>>>>>>> On Friday 24 of July 2015 21:55:00 Rohini Kulkarni wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I have attached the report containing outputs of >>>>>>>>>>>> arm-rtems4.11-size >>>>>>>>>>>> and >>>>>>>>>>>> arm-rtems4.11-nm -S. >>>>>>>>>>>> >>>>>>>>>>>> From arm-rtems4.11-nm -S I don't see how memset() is accessing >>>>>>>>>>>> .text >>>>>>>>>>>> section. The start and end values for both are not overlapping. >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Jul 24, 2015 at 7:03 PM, Gedare Bloom <ged...@gwu.edu> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Jul 24, 2015 at 3:30 AM, Rohini Kulkarni >>>>>>>>>>>>> <krohini1...@gmail.com> >>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 24 Jul 2015 12:35, "Sebastian Huber" < >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> sebastian.hu...@embedded-brains.de> >>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 23/07/15 23:24, Rohini Kulkarni wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I could finally get back to this issue. I used Pi 1 for >>>>>>>>>>>>>>>> debugging, >>>>>>>>>>>>>>>> but the reason for this problem will apply to Pi 2 also. >>>>>>>>>>>>>>>> With text section set to ARMV7_MMU_CODE_CACHED ( which >>>>>>>>>>>>>>>> implies >>>>>>>>>>>>>>>> read >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> only) >>>>>>>>>>>>> >>>>>>>>>>>>>>>> , a data abort exception occurs with memset() inside >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> bsp_start_clear_bss() >>>>>>>>>>>>> >>>>>>>>>>>>>>>> function. An illegal write access to an address according >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>> me. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Which exception and which address? Something is not >>>>>>>>>>>>>>> working >>>>>>>>>>>>>>> here. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is a part of the debugging output. When I used >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ARMV7_MMU_CODE_CACHED. >>>>>>>>>>>>> >>>>>>>>>>>>>> (gdb) s >>>>>>>>>>>>>> bsp_start_clear_bss () >>>>>>>>>>>>>> at >>>>>>>>>>>>>> ../../../../../.././raspberrypi/lib/include/bsp/start.h:126 >>>>>>>>>>>>>> 126 memset(bsp_section_bss_begin, 0, (size_t) >>>>>>>>>>>>>> bsp_section_bss_size); >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> What are the values of bsp_section_bss_begin, and >>>>>>>>>>>>> bsp_section_bss_size? >>>>>>>>>>>>> >>>>>>>>>>>>> Apparently, the memset is trying to write into the .text >>>>>>>>>>>>> (code) >>>>>>>>>>>>> section, which is a very bad thing to do indeed. >>>>>>>>>>>>> >>>>>>>>>>>>>> (gdb) s >>>>>>>>>>>>>> memset (m=0x1157e0, c=0, n=64176) >>>>>>>>>>>>>> at >>>>>>>>>>>>>> ../../../../../gcc-4.9.2/newlib/libc/string/memset.c:59 >>>>>>>>>>>>>> 59 ../../../../../gcc-4.9.2/newlib/libc/string/memset.c: >>>>>>>>>>>>>> No >>>>>>>>>>>>>> such >>>>>>>>>>>>>> file >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> or >>>>>>>>>>>>> >>>>>>>>>>>>>> directory. >>>>>>>>>>>>>> (gdb) s >>>>>>>>>>>>>> 49 in >>>>>>>>>>>>>> ../../../../../gcc-4.9.2/newlib/libc/string/memset.c >>>>>>>>>>>>>> (gdb) s >>>>>>>>>>>>>> _ARMV4_Exception_data_abort_default () >>>>>>>>>>>>>> at >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ../../../../../../../../rtems-local/rtems/c/src/../../cpukit/score/cpu/ar >>>>>>>>>>>>> m/armv4-exception-default.S:71 >>>>>>>>>>>>> >>>>>>>>>>>>>> 71 sub sp, #MORE_CONTEXT_SIZE >>>>>>>>>>>>>> >>>>>>>>>>>>>> When I set text section flag to ARMV7_MMU_READ_WRITE, the >>>>>>>>>>>>>> system >>>>>>>>>>>>>> starts >>>>>>>>>>>>>> successfully. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Sebastian Huber, embedded brains GmbH >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany >>>>>>>>>>>>>>> Phone : +49 89 189 47 41-16 >>>>>>>>>>>>>>> Fax : +49 89 189 47 41-09 >>>>>>>>>>>>>>> E-Mail : sebastian.hu...@embedded-brains.de >>>>>>>>>>>>>>> PGP : Public key available on request. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Diese Nachricht ist keine geschäftliche Mitteilung im >>>>>>>>>>>>>>> Sinne >>>>>>>>>>>>>>> des >>>>>>>>>>>>>>> EHUG. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> devel mailing list >>>>>>>>>>>>>> devel@rtems.org >>>>>>>>>>>>>> http://lists.rtems.org/mailman/listinfo/devel >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Rohini Kulkarni >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> devel mailing list >>>>>>>>>> devel@rtems.org >>>>>>>>>> http://lists.rtems.org/mailman/listinfo/devel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Rohini Kulkarni >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Rohini Kulkarni >>>>>> >>>>>> _______________________________________________ >>>>>> devel mailing list >>>>>> devel@rtems.org >>>>>> http://lists.rtems.org/mailman/listinfo/devel >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Rohini Kulkarni >> >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >> > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.com On-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available (256) 722-9985 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
