close Warning: The following arguments are missing: MILESTONE

{11} Ticket Change History (51 matches)

Arguments
Ticket Summary Version Milestone Created Modified Type Owner
Comments
#2361 Documentation for enabling stack checking is inaccurate 4.11 06/05/15 10/10/17 defect Gedare Bloom <gedare@…>
In [changeset:"fecc911b4161fc10de77cd73879a6208035811fd/rtems"]: {{{ #!CommitTicketReference repository="rtems" revision="fecc911b4161fc10de77cd73879a6208035811fd" doc: fix typo. closes #2361. }}}
#2361 Documentation for enabling stack checking is inaccurate 4.11 06/05/15 10/10/17 defect Gedare Bloom <gedare@…>

#2368 Documentation for Unlimited Objects needs updating 4.11 06/15/15 10/10/17 infra Joel Sherrill <joel.sherrill@…>
In [changeset:"e0938c2754528fbcdec9bd434e5e7732d2c850bf/rtems"]: {{{ #!CommitTicketReference repository="rtems" revision="e0938c2754528fbcdec9bd434e5e7732d2c850bf" user/conf.t: Fix names for CONFIGURE_UNLIMITED_OBJECTS and CONFIGURE_UNLIMITED_ALLOCATION_SIZE closes #2368. }}}
#2368 Documentation for Unlimited Objects needs updating 4.11 06/15/15 10/10/17 infra Joel Sherrill <joel.sherrill@…>

#2398 Set cross-compiler tool 4.6 08/28/15 08/14/17 enhancement

#2424 wiki/Developer/Git has broken link to github.com 09/27/15 09/27/15 defect
Fixed. Thanks.
#2475 Various bugfixes for rtems-source-builder 11/20/15 01/12/16 defect
Many thanks for the patches. attachment:01-file-url-bugfix Please add some white space around '!=' on line 27 attachment:02-rtems-kernel-4-1-url-patch Should we just define rtems_major_kernel_version where we define rtems_kernel_version? The use of sed here works but I feel it makes things fragile over time. Another solution is to add a way to split a version into parts within the RSB python code. I feel it would be more robust but I am happy to discuss this and see what is best. The remaining patches have a common issue. We do not put patches into the RSB. Patches go in the https://git.rtems.org/rtems-tools/tree/tools repo. Could please create the patches for that repo then please update the RSB to reference them. I can push the rtems-tools patches first so you can test.
#2475 Various bugfixes for rtems-source-builder 11/20/15 01/12/16 defect
Hello, as you suggested I have added some of the patches to my local copy of {{{git://git.rtems.org/rtems-tools.git}}}. I have added these as a patch bundle file "rtems-tools-patchbundle" to this ticket. You can apply this file with {{{git am < rtems-tools-patchbundle}}}.
#2475 Various bugfixes for rtems-source-builder 11/20/15 01/12/16 defect

#2475 Various bugfixes for rtems-source-builder 11/20/15 01/12/16 defect
Since the diff files from my patches 04-.. to 07-.. should be added to {{{git://git.rtems.org/rtems-tools.git}}}, these patches have to be changed. I have added new versions of these patches here.
#2475 Various bugfixes for rtems-source-builder 11/20/15 01/12/16 defect
Due to changes in the RSB in the recent weeks this ticket is now obsolete. The new tickets related to RSB and building RTEMS with RSB are: #2518 #2519 #2520 #2521 #2522 #2523
#2476 HELP: Trac thinks I'm a spammer 11/25/15 01/12/16 defect Amar Takhar

#2476 HELP: Trac thinks I'm a spammer 11/25/15 01/12/16 defect Amar Takhar
2016-01-12 Trac still thinks I'm a spammer. Today the system showed me captures and I'm sure I replied correctly but it still rejected my new trac report. Could you please remove me (host: tarn.acc.bessy.de, trac account: goetzpf) from you spam list ?
#2476 HELP: Trac thinks I'm a spammer 11/25/15 01/12/16 defect Amar Takhar
For future reference any RTEMS developer can fix this by going to: 1. https://devel.rtems.org/admin/general/perm 2. Add username in '''Subject:''' at the top 3. Giving user the 'NOTSPAM' permission I have fixed this now, apologies for the delay this ticket slipped my mind.
#2483 raspberrypi: i2c driver can block task forever if compiled with #if I2C_IO_MODE == 1 5 12/02/15 12/13/15 defect Jan Sommer <soja-lists@…>
The added patch should fix the problem. It simply writes the task_id of the current thread to the bus structure before waiting for the transient event. Then, the ISR should send the event to the correct task.
#2483 raspberrypi: i2c driver can block task forever if compiled with #if I2C_IO_MODE == 1 5 12/02/15 12/13/15 defect Jan Sommer <soja-lists@…>
In [changeset:"687463d7f3b0abb1d98e6e630fb6d47541594bd4/rtems"]: {{{ #!CommitTicketReference repository="rtems" revision="687463d7f3b0abb1d98e6e630fb6d47541594bd4" Store task_id of the current thread for the ISR before waiting for the transient event The ISR will send a transient event to the task specified in bus->taskid. Make sure that the correct task_id is written to this field before waiting for the transient event to arrive. Fixes #2483 }}}
#2489 www.rtems.org/license and the GoAhead HTTP server 12/11/15 07/28/17 defect
Ah I think we can get rid of the reference to GoAhead... Joel?
#2489 www.rtems.org/license and the GoAhead HTTP server 12/11/15 07/28/17 defect
I am fine with us removing the references.
#2489 www.rtems.org/license and the GoAhead HTTP server 12/11/15 07/28/17 defect
It's still in 4.8, 4.9 and 4.10... Found it hiding under cpukit/httpd
#2489 www.rtems.org/license and the GoAhead HTTP server 12/11/15 07/28/17 defect
I think I have addressed this long festering ticket.
#2612 R_ARM_GOT_BREL relocation type unsupported 4.11 02/24/16 02/25/16 enhancement Chris Johns
I have located this reloc record in object files I have. I am not sure what is happening here and why it is appearing. In some code I am seeing: {{{ 000000bc 00001d19 R_ARM_BASE_PREL 00000000 _GLOBAL_OFFSET_TABLE_ 000000c0 00001e1a R_ARM_GOT_BREL 00000004 hashtable_seed }}} and the code is: https://github.com/akheron/jansson/blob/master/src/hashtable.c#L31 I this is strange. The fact a _GLOBAL_OFFSET_TABLE_ value is present is strange for RTEMS. We do not use a GOT.
#2612 R_ARM_GOT_BREL relocation type unsupported 4.11 02/24/16 02/25/16 enhancement Chris Johns
Building this package from git for the Zynq does not seem to generate the reloc records. I am little confused by this.
#2612 R_ARM_GOT_BREL relocation type unsupported 4.11 02/24/16 02/25/16 enhancement Chris Johns
Is -fPIC being used when building the code?
#2612 R_ARM_GOT_BREL relocation type unsupported 4.11 02/24/16 02/25/16 enhancement Chris Johns
Yes, `-fPIC` is used.
#2612 R_ARM_GOT_BREL relocation type unsupported 4.11 02/24/16 02/25/16 enhancement Chris Johns
Please try dropping the -fPIC option on anything you have it on. I don't think you need it anyway. Chris can confirm when it he wakes up.
#2612 R_ARM_GOT_BREL relocation type unsupported 4.11 02/24/16 02/25/16 enhancement Chris Johns
Dropping `-fPIC` actually seems to resolve the `dlopen` failure. I'll still post the example program and Makefile so the error can be reproduced. With `-fPIC`: {{{ Relocation section '.rel.text' at offset 0x96c contains 4 entries: Offset Info Type Sym.Value Sym. Name 00000020 00001419 R_ARM_BASE_PREL 00000000 _GLOBAL_OFFSET_TABLE_ 00000024 0000121a R_ARM_GOT_BREL 00000004 global_variable 00000040 00001419 R_ARM_BASE_PREL 00000000 _GLOBAL_OFFSET_TABLE_ 00000044 0000121a R_ARM_GOT_BREL 00000004 global_variable }}} Without `-fPIC`: {{{ Relocation section '.rel.text' at offset 0x904 contains 4 entries: Offset Info Type Sym.Value Sym. Name 00000008 00000f2f R_ARM_THM_MOVW_AB 00000004 global_variable 0000000c 00000f30 R_ARM_THM_MOVT_AB 00000004 global_variable 00000024 00000f2f R_ARM_THM_MOVW_AB 00000004 global_variable 00000028 00000f30 R_ARM_THM_MOVT_AB 00000004 global_variable }}}
#2612 R_ARM_GOT_BREL relocation type unsupported 4.11 02/24/16 02/25/16 enhancement Chris Johns
I am glad dropping the -fPIC got rid of the unsupported relocation record. I don't know why you would want to build with that for RTEMS. My gut is this is the resolution. When Chris wakes up, he can make a ruling on what is the right thing long-term. It may or may not make sense to add support for this relocation record since we normally don't build with -fPIC. It is also possible that just adding an error message to say "don't build with -fPIC" when this record is seen isn't a bad idea. :)
#2612 R_ARM_GOT_BREL relocation type unsupported 4.11 02/24/16 02/25/16 enhancement Chris Johns
I'm glad you both caught that, it must have been leftover from porting our old Makefiles that were for Linux, and I just continued using it for the shared libraries. Here are instructions for the attachment: To generate code that causes the `dlopen` failure (omitting the override of `LIB_OPTS` will result in the test succeeding): {{{ make clean all LIB_OPTS=-fPIC }}} Test with QEMU: {{{ qemu-system-arm -m 256M -M xilinx-zynq-a9 -serial null \ -serial mon:stdio -nographic -no-reboot \ -kernel ./libdl-global-var-test.exe }}} One curiosity is that if the generated `lib.o` is loaded, rather than `lib.so`, there are unresolved symbols after the load. I haven't looked into why, but usually the plain object file is fine (the dl-01 test uses it, but also doesn't load global variables). This can be tested by changing line 15 of `libdl-global-var-test.c` to `#define LIB_FILE_NAME "/lib.o"`. The tar file loaded at run-time contains both files, so no other changes are necessary. Development environment (I forgot to include this in the original description): * RTEMS version: Branch "4.11", commit 2145853b009e939dfbe14869b710133f50500a26 * RTEMS configure options: `--target=arm-rtems4.11 --enable-rtemsbsp="xilinx_zynq_a9_qemu xilinx_zynq_zedboard" --enable-tests=samples --enable-posix --prefix=/home/patrick/development/rtems/4.11 --disable-networking` * `arm-rtems4.11-gcc --version` {{{ arm-rtems4.11-gcc (GCC) 4.9.3 20150626 (RTEMS 4.11, RSB aa3fdad01a0dbc3cbfd7c49e1ea07ff1a585c0b9 (HEAD, origin/4.11, 4.11)-modified, Newlib 2.2.0.20150423) }}}
#2612 R_ARM_GOT_BREL relocation type unsupported 4.11 02/24/16 02/25/16 enhancement Chris Johns
The -fPIC option is currently not supported. I have found -fPIC code when statically linked into the base image is fine so this shows the code is fine to run, it is just the need for this reloc record to be supported. It may prove in time the -fPIC option is something useful. Patrick are you able to count the relocation records with -fPIC and without? I am wondering if an -fPIC build has fewer relocation records because the code is already position independent. I will follow up your second issue about unresolved symbols once I get somewhere I can take a look.
#2612 R_ARM_GOT_BREL relocation type unsupported 4.11 02/24/16 02/25/16 enhancement Chris Johns
There are 4 records in `.rel.text` both with and without `-fPIC`. That's not including debug records, but it looks like those are also the same in number.
#2612 R_ARM_GOT_BREL relocation type unsupported 4.11 02/24/16 02/25/16 enhancement Chris Johns
Replying to [comment:10 pggauvin]: > There are 4 records in `.rel.text` both with and without `-fPIC`. That's not including debug records, but it looks like those are also the same in number. Thanks. It looks like -fPIC does not give us anything extra. I will leave the libdl code as is for now until the veneer support is added. Joel, I am not in favor of a special error message. It opens up a can of worms by requiring us to catch every possible case. Now we know we will be able to support this issue a little better.
#2612 R_ARM_GOT_BREL relocation type unsupported 4.11 02/24/16 02/25/16 enhancement Chris Johns
It may make sense to have a separate utility that can check the integrity of the files and relocation records. Basically ensure it is OK and understandable by loader. I know of a precedence for that with a toolset I have used in the past. Was handy when oddities showed up and a handy thing to include in the build process in case something turned up.
#2612 R_ARM_GOT_BREL relocation type unsupported 4.11 02/24/16 02/25/16 enhancement Chris Johns
This means we need to keep the reloc records handled by the target in sync with a tool on the host. What value does this provide? There are other options on gcc that can break the code we currently do not check for. I think suitable documentation will help as much.
#2612 R_ARM_GOT_BREL relocation type unsupported 4.11 02/24/16 02/25/16 enhancement Chris Johns
Just mentioning what I have seen done elsewhere. I know it is a maintenance burden and likely of little value since people will probably file a ticket before they run the tool. LOL
#2612 R_ARM_GOT_BREL relocation type unsupported 4.11 02/24/16 02/25/16 enhancement Chris Johns
We have the rtems-ld tool and that could do it. We would need to teach it about each arch and what is ok and what is not. I do hope our users run the code before they ship it as the target will tell them something is wrong. ;)
#2621 Address Cross Porting to Mailing Lists 03/02/16 08/14/17 defect Amar Takhar
Do not cross post, send emails to each list.
#2704 Weak symbols not found by loaded code 4.11 05/10/16 11/18/16 defect Chris Johns
Just ran into this same issue during development. Any new status on this ticket?
#2704 Weak symbols not found by loaded code 4.11 05/10/16 11/18/16 defect Chris Johns
I've attached a patch for rtems-syms in rtems-tools that includes any defined weak symbols in the base image into the symbol table it generates. This allows loaded code to find the symbols, but it is not a complete solution, since now a defined weak symbol in loaded code will cause a failed load if it is defined in the base image weakly, since the loader now believes it is a strong symbol. For what it's worth, the x86_64 loader on Linux seems to use the base's symbol in situations where the symbol is defined in both the base and loaded code (regardless of whether they are weak or strong).
#2704 Weak symbols not found by loaded code 4.11 05/10/16 11/18/16 defect Chris Johns
In [changeset:"ef4a46e0293111361c970a287c29a185905121b2/rtems-tools"]: {{{ #!CommitTicketReference repository="rtems-tools" revision="ef4a46e0293111361c970a287c29a185905121b2" linkers/syms: Add weak symbols to the global symbol table. Add any weak symbols that have been linked into the base image to the global symbol table. A weak symbol is global when view viewed from a dynamically loaded module. Closes #2704. }}}
#2704 Weak symbols not found by loaded code 4.11 05/10/16 11/18/16 defect Chris Johns
In [changeset:"885aebd6b34755198196a96825fc82b9fc4a0789/rtems-tools"]: {{{ #!CommitTicketReference repository="rtems-tools" revision="885aebd6b34755198196a96825fc82b9fc4a0789" linkers/syms: Add weak symbols to the global symbol table. Add any weak symbols that have been linked into the base image to the global symbol table. A weak symbol is global when view viewed from a dynamically loaded module. Closes #2704. }}}
#2704 Weak symbols not found by loaded code 4.11 05/10/16 11/18/16 defect Chris Johns
In [changeset:"ef4a46e0293111361c970a287c29a185905121b2/rtems-tools"]: {{{ #!CommitTicketReference repository="rtems-tools" revision="ef4a46e0293111361c970a287c29a185905121b2" linkers/syms: Add weak symbols to the global symbol table. Add any weak symbols that have been linked into the base image to the global symbol table. A weak symbol is global when view viewed from a dynamically loaded module. Closes #2704. }}}
#2704 Weak symbols not found by loaded code 4.11 05/10/16 11/18/16 defect Chris Johns
In [changeset:"ef4a46e0293111361c970a287c29a185905121b2/rtems-tools"]: {{{ #!CommitTicketReference repository="rtems-tools" revision="ef4a46e0293111361c970a287c29a185905121b2" linkers/syms: Add weak symbols to the global symbol table. Add any weak symbols that have been linked into the base image to the global symbol table. A weak symbol is global when view viewed from a dynamically loaded module. Closes #2704. }}}
#2744 Remove RBL blocking for mailing lists. 4.10 06/23/16 04/07/17 infra Amar Takhar
This was done months ago.
#2767 libdl exceptions throw/catch (ARM PREL31 and TARGET2 relocation support) 4.11 07/29/16 12/13/16 defect Chris Johns
Yes a review of the ARM's Exception Handling ABi shows both relocation types are used. The patch looks fine.
#2767 libdl exceptions throw/catch (ARM PREL31 and TARGET2 relocation support) 4.11 07/29/16 12/13/16 defect Chris Johns
I have investigated the reason 'terminate' is called when the throw and catch happens in the dynamic module. Terminate is called because the exception processing code resident in the base image does not see the exception data in the dynamically loaded module, it only has access to the exception data in the base image. The problem space is made more complex because each arch can have a specific way of handling exceptions. A possible solution for ARM may not be available for other architectures. A quick review of the libgcc code responsible for handling run-time exceptions shows a possible solution for ARM via a weak function and the other architectures are DWARF based.
#2767 libdl exceptions throw/catch (ARM PREL31 and TARGET2 relocation support) 4.11 07/29/16 12/13/16 defect Chris Johns

#2767 libdl exceptions throw/catch (ARM PREL31 and TARGET2 relocation support) 4.11 07/29/16 12/13/16 defect Chris Johns
In [changeset:"c6eead1353e03542e5bad9efda3b6553125520d8/rtems"]: {{{ #!CommitTicketReference repository="rtems" revision="c6eead1353e03542e5bad9efda3b6553125520d8" libdl: Add C++ exception support to loaded modules. This has been tested on SPARC, i386, PowerPC and ARM. Closes #2767. }}}
#2781 Information about network protocols 08/31/16 09/01/16 defect
Hi MisH, I suggest you post to the users@rtems.org mailing list. There is a wider audience. Chris
#2781 Information about network protocols 08/31/16 09/01/16 defect
Hi Chris, can u also tell me where i can do this ? Im kinda new to this and dont know where to go.... MisH
#2781 Information about network protocols 08/31/16 09/01/16 defect
MisH: You can get an excellent introduction to all things "RTEMS" by starting from https://devel.rtems.org/wiki/GSoC/GettingStarted and following some of the links. For example there is a link to a page describing the mailing lists. The page also explains how to easily get RTEMS running inside of a simulated CPU.
#2804 Add http(s) paths to git.rtems.org repos 5 11/07/16 08/14/17 infra
Use github.
Note: See TracReports for help on using and creating reports.