<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 29, 2018 at 11:26 AM, Amaan Cheval <span dir="ltr"><<a href="mailto:amaan.cheval@gmail.com" target="_blank">amaan.cheval@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, May 29, 2018 at 9:28 PM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>> wrote:<br>
> Noted, thanks a ton for the details! Unrelated to the topic at hand,<br>
> but out of interest, is this the only reading material for further<br>
> details? <a href="http://ceur-ws.org/Vol-1697/EWiLi16_12.pdf" rel="noreferrer" target="_blank">http://ceur-ws.org/Vol-1697/<wbr>EWiLi16_12.pdf</a><br>
><br>
> In brief: My tests for keeping a libfake.a (compiled without -fpic)<br>
> and a loader.so with a user-appXYZ.c have been successful, but I'm not<br>
> sure if my assumptions hold for all cases. See the details below for<br>
> more.<br>
><br>
> Next actions:<br>
> - Read more of Linkers and Loaders since it seems to be the only<br>
> detailed resource I've found at this point<br>
> - Experiment with actually using the existing librtems*.a I've got and<br>
> making them boot as a PE UEFI application image<br>
><br>
> ------------------------------<wbr>------------------------------<wbr>--------------------<br>
><br>
> In more detail:<br>
><br>
> The problem:<br>
> That UEFI needs a relocatable PE file, i.e. one that can function<br>
> regardless of the physical address it's loaded at (no virtual<br>
> addresses that early).<br>
> To build an ELF of that kind, the resources I've seen all build their<br>
> source with -fpic, and then use objcopy to convert the ELF into a<br>
> relocatable PE, with an embedded runtime self-relocator (akin to<br>
> load-time relocation, if I'm understanding correctly).<br>
><br>
> What Joel suggested seems to be the simplest option - see if not using<br>
> -fpic for _all_ of RTEMS' build system is fine. I think it might be<br>
> from some testing, but I'm not sure if this is conclusive since I need<br>
> to understand the specifics of the entire development process better.<br>
><br>
> So here's my understanding of the situation at the moment:<br>
><br>
> - librtems*.a is made up of object files, compiled without -fpic, and<br>
> that should be fine because I believe object files will use RIP<br>
> relative addressing code by default on x64 where it can, and leave the<br>
> rest for link-time relocations to handle. IF this is true, this works<br>
> perfectly for us because all memory accesses and jumps/calls are<br>
> relative.<br></div></div></blockquote><div><br></div><div>Just to be clear. For Deos, I am compiling all code with -fPIC. This</div><div>includes all librtemscpu.a and librtemsbsp.a. When I accidentally</div><div>missed an adapter file, that caused an issue.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
><br>
> - We can have a loader.c which acts as the core with the efi_main<br>
> function - compile it with -fpic into loader.so, and then link<br>
> loader.so, librtems*.a, and user-appXYZ.c together to form a<br>
> relocatable ELF, then convert it into a PE using objcopy. Note that<br>
> from what I can tell, the ELF generated from this still has type EXEC,<br>
> not DYN, according to readelf.<br>
<br>
</div></div>Correction: This was a leftover file that I'd forgotten to take out<br>
after renaming a target. Sorry about the confusion. Just using the<br>
"-shared" flag does cause the resulting ELF to be of type DYN.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> The concerns I have are about my assumptions; if GCC generates any<br>
> code that uses absolute addressing and that is resolved as a link-time<br>
> relocation, that could be problematic because the final relocatable PE<br>
> may not match up with the resolved absolute address.<br></div></div></blockquote><div><br></div><div>The Deos kernel guys had me check readelf on a known good executable</div><div>with the ones I was producing. The loadable sections should match up.</div><div>For example, on one architecture I missed an alignment in the linkcmds</div><div>and on another, an argument hidden in bsp_specs made a section writable</div><div>which should have been read-only. Just check what you can with readelf</div><div>and objdump section headers.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
><br>
> My tests with a fake static archive library, and creating a PE have<br>
> been successful, but I'm unsure of how to trigger the relocation<br>
> behavior by the UEFI firmware (i.e. loading the UEFI image at an<br>
> address other than it's preferred one). One idea is to have a UEFI<br>
> application image that loads this test UEFI application image through<br>
> the "LoadImage" function UEFI provides as a service and then to use<br>
> QEMU's monitor / gdb inspection capabilities to see if the address the<br>
> image is loaded at genuinely changes.<br></div></div></blockquote><div><br></div><div>That's the question. Does the executable end up at a reliably known address?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
><br>
> If any of you have any resources, that'd be highly appreciated. Some<br>
> resources I'm using so far are:<br>
> - <a href="https://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/" rel="noreferrer" target="_blank">https://eli.thegreenplace.net/<wbr>2011/11/03/position-<wbr>independent-code-pic-in-<wbr>shared-libraries/</a><br>
> - <a href="https://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries/" rel="noreferrer" target="_blank">https://eli.thegreenplace.net/<wbr>2011/08/25/load-time-<wbr>relocation-of-shared-<wbr>libraries/</a><br>
> - <a href="https://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models" rel="noreferrer" target="_blank">https://eli.thegreenplace.net/<wbr>2012/01/03/understanding-the-<wbr>x64-code-models</a><br>
><br>
> Sorry about the length of the email!<br>
><br>
> On Fri, May 25, 2018 at 10:51 PM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br>
>><br>
>><br>
>> On Fri, May 25, 2018, 12:11 PM Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>> wrote:<br>
>>><br>
>>> Hey! Could you link me to some code that you used for the Deos setup<br>
>>> you mentioned?<br>
>>> My understanding is that the -shared option can link static archives<br>
>>> to create a "shared" library in the sense that it doesn't include the<br>
>>> usual crt0 runtime environment and whatnot, but the code within is<br>
>>> still position-dependent. Given that the PE image that EFI needs is<br>
>>> one that needs to be truly relocatable, this may not work - BUT, I've<br>
>>> only just noticed the ./gnuefi/reloc_x86_64.c file which seems to<br>
>>> handle some kinds of runtime relocations encoded within the converted<br>
>>> PE file, so maybe this will work after all. I'll continue to<br>
>>> investigate and let you know how it goes!<br>
>><br>
>><br>
>> Deos isn't a good example except that you can compile with -fPIC and put<br>
>> that code into a static library. Deos is a closed source Level A (man rated<br>
>> flight) ARINC 653 RTOS. It's boot process reads configuration information<br>
>> about each partition and associates .so's with each address space per the<br>
>> configuration. It can't change after that.<br>
>><br>
>> The RTEMS exe is mostly linked as normal except to use some arguments to say<br>
>> some symbols are from a shared library.<br>
>><br>
>> The base address of the exe is that of the provided virtual address space<br>
>> with .data and .bss in their respective spaces.<br>
>><br>
>> And our entry point is in C so there is no asm before that. Great<br>
>> simplification.<br>
>><br>
>>><br>
>>> Regarding how TLS differs with PIC - could you elaborate? Is it<br>
>>> something we'll need to solve for if we go with the -fPIC option, or<br>
>>> is it something we need to keep in mind as a limitation, but isn't<br>
>>> really a blocker?<br>
>><br>
>><br>
>> I don't think PIC changes the TLS mechanism on arm or PowerPC but on i386,<br>
>> when not PIC the TLS base is in %gs and it's a subroutine call when PIC.<br>
>> Just as well for Deos since they assume an application won't change the<br>
>> segment register values.<br>
>><br>
>> Other than this one TLS difference, it is a normal exe to me. They just<br>
>> magically provide their .so's before we run.<br>
>>><br>
>>><br>
>>> On Fri, May 25, 2018 at 10:13 PM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br>
>>> ><br>
>>> ><br>
>>> > On Fri, May 25, 2018, 11:15 AM Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> Hey!<br>
>>> >><br>
>>> >> Skippable details about how FreeBSD handles the UEFI boot process!<br>
>>> >><br>
>>> >><br>
>>> >> ------------------------------<wbr>------------------------------<wbr>--------------------<br>
>>> >><br>
>>> >> Having looked into it a bit more, my understanding of how FreeBSD<br>
>>> >> handles this process is:<br>
>>> >> - They build a two-stage bootloader for EFI, called boot1.efi and<br>
>>> >> loader.efi[1]<br>
>>> >> - loader.efi is an interactive prompt which may autoboot, or a "boot<br>
>>> >> kernelImg" command can be used to load the actual kernel<br>
>>> >> - The kernel is loaded as an ELF through helper functions. The<br>
>>> >> command_boot[2] function drives this:<br>
>>> >>   - In brief, through calls go through:<br>
>>> >>     command_boot -> mod_loadkld -> file_load -><br>
>>> >> file_formats[i]->l_load (actually the loadfile function in<br>
>>> >> load_elf.c[3])<br>
>>> >>   - The loadfile function parses the program and section headers of<br>
>>> >> the ELF file (through more function detours that are not really<br>
>>> >> important)<br>
>>> >>   - Once the ELF has been loaded at the correct entry_addr that it<br>
>>> >> expects to be loaded at in memory, the l_exec[4] function is called,<br>
>>> >> which is actually elf64_exec in elf64_freebsd.c[5], at which hopefully<br>
>>> >> through trampolining magic, the control flow will transfer to the<br>
>>> >> kernel or ELF module<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> ------------------------------<wbr>------------------------------<wbr>--------------------<br>
>>> >><br>
>>> >> What this means for RTEMS if we go with gnu-efi is essentially 2<br>
>>> >> options, given that the objcopy method of converting from ELF->PE<br>
>>> >> requires the ELF to be a position-independent shared library:<br>
>>> >><br>
>>> >> - Using -fPIC to compile all of RTEMS, including the RTEMS user's<br>
>>> >> application code. This way we'd have librtemsbso.so, librtemscpu.so,<br>
>>> >> etc. which would then be linked into user_app.c through -fPIC and<br>
>>> >> -shared flags still, creating one singular hello.so, which can then<br>
>>> >> finally be converted into hello.efi and put on a FAT filesystem and<br>
>>> >> booted. This seems doable, but I'm fairly concerned about it further<br>
>>> >> complicating our build system and likely being quite singular in its<br>
>>> >> focus on EFI.<br>
>>> ><br>
>>> ><br>
>>> > I'm using PIC on the Deos BSP. RTEMS is still a .a and exes are linked<br>
>>> > with<br>
>>> > our static libraries and Deos .so.<br>
>>> ><br>
>>> > Unless the loader forces something, you can use PIC with no build system<br>
>>> > changes.<br>
>>> ><br>
>>> > note that thread local storage is different on i386 with and without<br>
>>> > PIC.<br>
>>> >><br>
>>> >><br>
>>> >> - The FreeBSD way of a (loader.efi) and a hello.exe (ELF64) put on<br>
>>> >> possibly the same partition on the FAT filesystem required for UEFI<br>
>>> >> application images anyway. The loader.efi can find the hello.exe file<br>
>>> >> through perhaps a config file it can read or by having a magic-name<br>
>>> >> like rtems.exe or something. This effectively means we need an ELF<br>
>>> >> dynamic linker / loader (akin to ld.so) within RTEMS' source. I think<br>
>>> >> using FreeBSD's code for this should be fine. One added benefit of<br>
>>> >> this method is that librtems* and user applications remain as ELF64s,<br>
>>> >> which in the future could also be used with Multiboot with a slightly<br>
>>> >> modified "loader" (i.e. one which generates the apt Multiboot magic<br>
>>> >> header, and boots the PC from 32-bit protected mode to 64-bit long<br>
>>> >> mode).<br>
>>> >><br>
>>> >> I prefer the latter approach personally. If both of these seem too<br>
>>> >> complicated, we can of course go back to considering generating the PE<br>
>>> >> header format in ASM the way Linux distros use EFISTUB and the code<br>
>>> >> Chris shared (as I mentioned in my original blog post) for wimboot.<br>
>>> >> Those approaches may be significantly simpler in a sense, but may<br>
>>> >> limit how we use UEFI Services - I'm not sure about the details of<br>
>>> >> this yet - I can investigate if y'all aren't fond of the option I laid<br>
>>> >> down above.<br>
>>> >><br>
>>> >> Let me know!<br>
>>> >><br>
>>> >> [1]<br>
>>> >><br>
>>> >> <a href="https://www.freebsd.org/cgi/man.cgi?query=loader&apropos=0&sektion=8&manpath=FreeBSD+11.1-RELEASE+and+Ports&arch=default&format=html" rel="noreferrer" target="_blank">https://www.freebsd.org/cgi/<wbr>man.cgi?query=loader&apropos=<wbr>0&sektion=8&manpath=FreeBSD+<wbr>11.1-RELEASE+and+Ports&arch=<wbr>default&format=html</a><br>
>>> >> [2]<br>
>>> >><br>
>>> >> <a href="https://github.com/freebsd/freebsd/blob/433bd38e3a0349f9f89f9d54594172c75b002b74/stand/common/boot.c#L53" rel="noreferrer" target="_blank">https://github.com/freebsd/<wbr>freebsd/blob/<wbr>433bd38e3a0349f9f89f9d54594172<wbr>c75b002b74/stand/common/boot.<wbr>c#L53</a><br>
>>> >> [3]<br>
>>> >><br>
>>> >> <a href="https://github.com/freebsd/freebsd/blob/d8596f6f687a64b994b065f3058155405dfc39db/stand/common/load_elf.c#L150" rel="noreferrer" target="_blank">https://github.com/freebsd/<wbr>freebsd/blob/<wbr>d8596f6f687a64b994b065f3058155<wbr>405dfc39db/stand/common/load_<wbr>elf.c#L150</a><br>
>>> >> [4]<br>
>>> >><br>
>>> >> <a href="https://github.com/freebsd/freebsd/blob/433bd38e3a0349f9f89f9d54594172c75b002b74/stand/common/boot.c#L107" rel="noreferrer" target="_blank">https://github.com/freebsd/<wbr>freebsd/blob/<wbr>433bd38e3a0349f9f89f9d54594172<wbr>c75b002b74/stand/common/boot.<wbr>c#L107</a><br>
>>> >> [5]<br>
>>> >><br>
>>> >> <a href="https://github.com/freebsd/freebsd/blob/d8596f6f687a64b994b065f3058155405dfc39db/stand/efi/loader/arch/amd64/elf64_freebsd.c#L93" rel="noreferrer" target="_blank">https://github.com/freebsd/<wbr>freebsd/blob/<wbr>d8596f6f687a64b994b065f3058155<wbr>405dfc39db/stand/efi/loader/<wbr>arch/amd64/elf64_freebsd.c#L93</a><br>
>>> >><br>
>>> >> On Sun, May 20, 2018 at 10:52 PM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br>
>>> >> ><br>
>>> >> ><br>
>>> >> > On Sun, May 20, 2018, 12:10 PM Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>><br>
>>> >> > wrote:<br>
>>> >> >><br>
>>> >> >> On Sat, May 19, 2018 at 6:51 PM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>><br>
>>> >> >> wrote:<br>
>>> >> >> > On Fri, May 18, 2018 at 5:53 PM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>><br>
>>> >> >> > wrote:<br>
>>> >> >> >><br>
>>> >> >> >><br>
>>> >> >> >> On Fri, May 18, 2018 at 3:24 PM, Amaan Cheval<br>
>>> >> >> >> <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>><br>
>>> >> >> >> wrote:<br>
>>> >> >> >>><br>
>>> >> >> >>> Hi everyone!<br>
>>> >> >> >>><br>
>>> >> >> >>> I've written a quick blog post summarizing the options I've<br>
>>> >> >> >>> considered<br>
>>> >> >> >>> to make the x86_64 port work with UEFI firmware - the primary<br>
>>> >> >> >>> winner<br>
>>> >> >> >>> seems to be in my eyes to use "gnu-efi" and to add support for<br>
>>> >> >> >>> the<br>
>>> >> >> >>> target "pei-x86-64" (aliased to "efi-app-x86_64") to<br>
>>> >> >> >>> "x86_64-rtems5-objcopy" in binutils. I've submitted a patch for<br>
>>> >> >> >>> this<br>
>>> >> >> >>> here[1].<br>
>>> >> >> >><br>
>>> >> >> >><br>
>>> >> >> >> That patch is quite simple so shouldn't be a problem if this is<br>
>>> >> >> >> the<br>
>>> >> >> >> direction<br>
>>> >> >> >> that gets consensus.<br>
>>> >> >> >>><br>
>>> >> >> >>><br>
>>> >> >> >>> The blog post is here:<br>
>>> >> >> >>> <a href="https://blog.whatthedude.com/post/uefi-app-options/" rel="noreferrer" target="_blank">https://blog.whatthedude.com/<wbr>post/uefi-app-options/</a><br>
>>> >> >> >>><br>
>>> >> >> >>> I'd appreciate all feedback (and please do let me know if I<br>
>>> >> >> >>> haven't<br>
>>> >> >> >>> provided enough context)!<br>
>>> >> >> >>><br>
>>> >> >> >>> Specifically, some concerns I'd like to discuss are:<br>
>>> >> >> >>><br>
>>> >> >> >>> - Does everyone agree with me on choosing gnu-efi + objcopy as<br>
>>> >> >> >>> our<br>
>>> >> >> >>> method of choice?<br>
>>> >> >> >><br>
>>> >> >> >><br>
>>> >> >> >> Does using gnu-efi add code that runs on the target? Can you<br>
>>> >> >> >> point<br>
>>> >> >> >> us to the files, if so.<br>
>>> >> >><br>
>>> >> >> Sure. The files would run on the target, yes. These are the ones<br>
>>> >> >> listed here (as linked to in my blog post, perhaps without<br>
>>> >> >> sufficient<br>
>>> >> >> emphasis):<br>
>>> >> >> <a href="https://wiki.osdev.org/UEFI#Developing_with_GNU-EFI" rel="noreferrer" target="_blank">https://wiki.osdev.org/UEFI#<wbr>Developing_with_GNU-EFI</a><br>
>>> >> >><br>
>>> >> >> >><br>
>>> >> >> >> Can you tell which approach FreeBSD takes?<br>
>>> >> >><br>
>>> >> >> FreeBSD takes the gnu-efi approach I see as the "winner" here (also<br>
>>> >> >> a<br>
>>> >> >> link in the post):<br>
>>> >> >><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >> <a href="https://github.com/freebsd/freebsd/blob/996b0b6d81cf31cd8d58af5d8b45f0b4945d960d/stand/efi/loader/Makefile#L98-L1" rel="noreferrer" target="_blank">https://github.com/freebsd/<wbr>freebsd/blob/<wbr>996b0b6d81cf31cd8d58af5d8b45f0<wbr>b4945d960d/stand/efi/loader/<wbr>Makefile#L98-L1</a><br>
>>> >> ><br>
>>> >> ><br>
>>> >> > This is (no surprise) appropriately licensed and IMO the winning<br>
>>> >> > solution.<br>
>>> >> > Knowing it is what FreeBSD does makes it an easy choice.<br>
>>> >> ><br>
>>> >> > A comment in the readme mentions there is a i386 version of this code<br>
>>> >> > so<br>
>>> >> > that could be used to let pc386 boot from UEFI.<br>
>>> >> ><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >> >><br>
>>> >> >> >>><br>
>>> >> >> >>> - How do we integrate gnu-efi into our build process? A part of<br>
>>> >> >> >>> the<br>
>>> >> >> >>> RSB, making sure the path to the libraries are in an exported<br>
>>> >> >> >>> variable? Or perhaps a part of the RTEMS kernel itself if the<br>
>>> >> >> >>> licenses<br>
>>> >> >> >>> are compatible (I don't see any on the project[2], only<br>
>>> >> >> >>> copyright<br>
>>> >> >> >>> notices within the source files of the release versions).<br>
>>> >> >> >><br>
>>> >> >> >><br>
>>> >> >> >> GNU-efi would be built like qemu or the device tree compiler<br>
>>> >> >> >> would<br>
>>> >> >> >> be my guess and x86_64-rtems toolset might add that to the<br>
>>> >> >> >> standard<br>
>>> >> >> >> set of tools. License on host tools being GPL isn't an issue.<br>
>>> >> >> >><br>
>>> >> >> ><br>
>>> >> >> > It appears to be a standard 2-clause BSD released by Intel as<br>
>>> >> >> > specified in the README file of gnu-efi.<br>
>>> >> >> ><br>
>>> >> >> >><br>
>>> >> >> >>><br>
>>> >> >> >>> - Regardless of how we manage UEFI, do we require Multiboot<br>
>>> >> >> >>> support<br>
>>> >> >> >>> too? Multiboot drops us in a 32-bit protected mode environment,<br>
>>> >> >> >>> whereas 64-bit UEFI firmware will boot us into 64-bit long mode<br>
>>> >> >> >>> -<br>
>>> >> >> >>> this<br>
>>> >> >> >>> would mean the kernel would need to support separate code-paths<br>
>>> >> >> >>> for<br>
>>> >> >> >>> the 2 if we want to support both methods.<br>
>>> >> >> >><br>
>>> >> >> >><br>
>>> >> >> >> That's a good question. For GSoC, I think UEFI is fine and<br>
>>> >> >> >> perhaps a<br>
>>> >> >> >> ticket<br>
>>> >> >> >> under the general "modern PC support" ticket for multiboot<br>
>>> >> >> >> support.<br>
>>> >> >> >> Unless<br>
>>> >> >> >> that eliminates a LOT of PCs.<br>
>>> >> >> >><br>
>>> >> >> >> I don't want you to spend all summer getting an image to boot<br>
>>> >> >> >> both<br>
>>> >> >> >> ways. Personally, I want you to have a working BSP one way. :)<br>
>>> >> >> > +1<br>
>>> >> >> ><br>
>>> >> >><br>
>>> >> >> Noted, thanks!<br>
>>> >> >><br>
>>> >> >> >>><br>
>>> >> >> >>><br>
>>> >> >> >>> [1] <a href="https://www.sourceware.org/ml/binutils/2018-05/msg00197.html" rel="noreferrer" target="_blank">https://www.sourceware.org/ml/<wbr>binutils/2018-05/msg00197.html</a><br>
>>> >> >> >>> [2] <a href="https://sourceforge.net/projects/gnu-efi/" rel="noreferrer" target="_blank">https://sourceforge.net/<wbr>projects/gnu-efi/</a><br>
>>> >> >> >><br>
>>> >> >> >><br>
>>> >> >> >> --joel<br>
>>> >> >> >><br>
>>> >> >> >> ______________________________<wbr>_________________<br>
>>> >> >> >> devel mailing list<br>
>>> >> >> >> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
>>> >> >> >> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div></div>