Re: MIPS Creator CI20 patches (again)

[Paul Boddie]

On Monday 5. February 2018 01.43.55 Paul Boddie wrote:
> 
> No, but the serial output isn't being done reliably in a physical sense, so
> that might be my fault rather than anything the software is doing. Is there
> some kind of assembly language file I should be looking at in the bootstrap
> package, just to see where this all gets started?

Answering my own question here - sorry if this preempts a response! - I can 
see the following files of interest:

pkg/bootstrap/server/src/ARCH-mips/crt0.S

This should be the first code that runs. Here, I think I probably need to 
configure the exception base to let me put exception entry points in a 
different location (as mentioned previously). I tested this with my simple 
boot payload, and the Ingenic SoC supports it, thankfully.

It also looks like I should only map 16MB pages for the bootstrap memory, not 
256MB pages for which the bit pattern employed for the pagemask doesn't look 
correct. But since the CI20 boots then perhaps the code somehow does the right 
thing (and I haven't checked the JZ4780 manual in case this is documented 
there). Finally, I see that the FPU is enabled, but the JZ4740 doesn't have 
one, so I omit that code. (I'm using a soft-float compiler made using 
Buildroot, by the way.)

src/kernel.mips.ld

This positions various things in the kernel. Here, I want to move the 
exception routines to the revised exception base, which appears possible by 
setting EXC_BASE. Inspecting the kernel using objdump, I see that the routines 
are moved when I do this.

So far, I haven't had any "breakthrough", but I guess it is a matter of 
working through the code and identifying any potential pitfalls, such as 
loading code into the neighbourhood of 0x8000 which definitely prevents 
booting. Many things can be present to prevent things from working, but it 
only takes one of them to still be present to have the same undesirable 
overall effect.

Anyway, sorry for the noise!

Paul

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: MIPS Creator CI20 patches (again)

[Paul Boddie]

On Monday 5. February 2018 00.02.47 Adam Lackorzynski wrote:
> On Fri Feb 02, 2018 at 16:45:13 +0100, Paul Boddie wrote:
> > 
> > There seems to be a "kernel" UART, but the userspace seems to have the
> > configuration details in l4/pkg/bootstrap/server/src/platform for each
> > board. Does the kernel somehow delegate the configuration to the
> > bootstrap component or is there somewhere in the kernel that needs to be
> > changed for the "kernel" UART? It also makes me wonder about how the jdb
> > communications are configured.
> 
> It's the other way around. The booting begins with bootstrap, that's
> where the first output happens. Bootstrap then passes the UART config on
> to Fiasco, i.e. the UART config that is used in bootstrap is also used
> by Fiasco. Do you see the initial output of bootstrap?

No, but the serial output isn't being done reliably in a physical sense, so 
that might be my fault rather than anything the software is doing. Is there 
some kind of assembly language file I should be looking at in the bootstrap 
package, just to see where this all gets started?

In fact, I remembered that the Ben NanoNote has rather awkward requirements 
with regard to where code gets loaded while booting, so I am starting to think 
that I need to figure this out first. Fiasco puts things in the usual place 
for MIPS, but this may conflict with the device bootloader.

Previously, I've followed what others have done, deployed code at some "non-
harmful" address and then copied code into place. This affects things like 
exception vectors which cannot apparently be populated directly (at 
0x8000) when the code is loaded. There is an actual reason for this, but I 
would have to review various mails and documentation to tell you. But it is 
related to the bootloader.

I'm experimenting with changing the location of the exception vectors, which 
should be possible as long as the EBASE coprocessor register is properly 
supported. I've actually played with this on PIC32MX devices, but I don't know 
how much the Ingenic devices support it. This might then make it possible to 
put the exception handlers in a different place, avoiding those bootloader 
conflicts, and hopefully get the kernel started.

Anyway, that was more than I intended to write. Thanks for following up again!

Paul

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: MIPS Creator CI20 patches (again)

[Adam Lackorzynski]

On Fri Feb 02, 2018 at 16:45:13 +0100, Paul Boddie wrote:
> On Wednesday 10. January 2018 00.48.03 Adam Lackorzynski wrote:
> > 
> > Adding the .global to the asm block makes thread2 a global symbol which
> > I'd like not to have here (contrary to L4UTIL_THREAD_FUNC). Just doing
> > "static void thread2()" gives warnings because there is no
> > implementation. Looks to me that having a function is much better here.
> > I'll have a look into this.
> > 
> > Thanks for investigating this. And also thanks to James for the nice
> > explanation of the issue.
> 
> I added a patch that works around this problem (l4util-mips-thread.diff) to 
> my 
> collection:
> 
> http://www.boddie.org.uk/paul/L4Re-Fiasco.OC.html
> 
> (Yes, it's the easiest/laziest approach!)
> 
> I have also been trying to extend the CI20 (JZ4780) support to the Ben 
> NanoNote (JZ4740), but success is still out of my reach in this regard. 
> Currently, the NanoNote is refusing to use the serial pins, having done so 
> before from Linux (but not currently, which is worrying), but it has made me 
> wonder about a few aspects of the UART configuration.
> 
> There seems to be a "kernel" UART, but the userspace seems to have the 
> configuration details in l4/pkg/bootstrap/server/src/platform for each board. 
> Does the kernel somehow delegate the configuration to the bootstrap component 
> or is there somewhere in the kernel that needs to be changed for the "kernel" 
> UART? It also makes me wonder about how the jdb communications are configured.

It's the other way around. The booting begins with bootstrap, that's
where the first output happens. Bootstrap then passes the UART config on
to Fiasco, i.e. the UART config that is used in bootstrap is also used
by Fiasco. Do you see the initial output of bootstrap?


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: MIPS Creator CI20 patches (again)

[Paul Boddie]

On Wednesday 10. January 2018 00.48.03 Adam Lackorzynski wrote:
> 
> Adding the .global to the asm block makes thread2 a global symbol which
> I'd like not to have here (contrary to L4UTIL_THREAD_FUNC). Just doing
> "static void thread2()" gives warnings because there is no
> implementation. Looks to me that having a function is much better here.
> I'll have a look into this.
> 
> Thanks for investigating this. And also thanks to James for the nice
> explanation of the issue.

I added a patch that works around this problem (l4util-mips-thread.diff) to my 
collection:

http://www.boddie.org.uk/paul/L4Re-Fiasco.OC.html

(Yes, it's the easiest/laziest approach!)

I have also been trying to extend the CI20 (JZ4780) support to the Ben 
NanoNote (JZ4740), but success is still out of my reach in this regard. 
Currently, the NanoNote is refusing to use the serial pins, having done so 
before from Linux (but not currently, which is worrying), but it has made me 
wonder about a few aspects of the UART configuration.

There seems to be a "kernel" UART, but the userspace seems to have the 
configuration details in l4/pkg/bootstrap/server/src/platform for each board. 
Does the kernel somehow delegate the configuration to the bootstrap component 
or is there somewhere in the kernel that needs to be changed for the "kernel" 
UART? It also makes me wonder about how the jdb communications are configured.

Maybe I missed all of this in the documentation, although if I can't get the 
pins to work then it does remain somewhat hypothetical for my circumstances, 
admittedly.

Paul

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: MIPS Creator CI20 patches (again)

[Adam Lackorzynski]

On Tue Jan 09, 2018 at 23:17:10 +0100, Paul Boddie wrote:
> On Tuesday 9. January 2018 01.02.58 Paul Boddie wrote:
> > 
> > So, I am assuming that the compiler gets confused by the freestanding
> > assembly language definition of the function, and the object goes missing
> > in some way that then leads to the error. Of course, the above introduces
> > other operations that are superfluous, but perhaps not harmful, due to the
> > general boilerplate included in C-level functions.
> > 
> > Anyway, I'll see if I get any response from the other discussion.
> 
> Well, I got a response that effectively describes the cause of the problem:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884821#25
> 
> As I understand it, the assembly language code defines a local object (the 
> default behaviour), but the C compiler regards it as a global object due to 
> the declaration used:
> 
> void __attribute__((visibility("internal"))) thread2(void);
> 
> Consequently, the linker complains about this inconsistency (but also seems 
> to 
> experience an error generating the error message).
> 
> What I see from the mybuild/include/mips/l4/util/thread.h file are two macros 
> for defining and declaring thread functions:
> 
> - L4UTIL_THREAD_FUNC introduces a global object wrapping the actual function
> 
> - L4UTIL_THREAD_STATIC_FUNC introduces a local object wrapping the actual 
> function, declaring it at the C level as a global, internal object
> 
> Since we are dealing with the output of the latter macro, it seems that there 
> are two main alternatives that suppress the error:
> 
> - Add a ".global" directive for the introduced wrapper object in the assembly 
> language (as is done by the former macro), producing a global but internal 
> object
> 
> - Declare the object at the C level as a static object, as in...
> 
>   static void thread2(void);
> 
> Another solution could involve using a C-level wrapper function and including 
> assembly language inside that, if necessary. Maybe someone (Sarah?) could say 
> what the motivations were for doing it in the current way. My hypothesis is 
> that extra instructions get generated for the C functions that are either 
> superfluous or harmful, such as accessing the stack, but I would gladly be 
> corrected.

Adding the .global to the asm block makes thread2 a global symbol which
I'd like not to have here (contrary to L4UTIL_THREAD_FUNC). Just doing
"static void thread2()" gives warnings because there is no
implementation. Looks to me that having a function is much better here.
I'll have a look into this.

Thanks for investigating this. And also thanks to James for the nice
explanation of the issue.



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: MIPS Creator CI20 patches (again)

[Paul Boddie]

On Tuesday 9. January 2018 01.02.58 Paul Boddie wrote:
> 
> So, I am assuming that the compiler gets confused by the freestanding
> assembly language definition of the function, and the object goes missing
> in some way that then leads to the error. Of course, the above introduces
> other operations that are superfluous, but perhaps not harmful, due to the
> general boilerplate included in C-level functions.
> 
> Anyway, I'll see if I get any response from the other discussion.

Well, I got a response that effectively describes the cause of the problem:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884821#25

As I understand it, the assembly language code defines a local object (the 
default behaviour), but the C compiler regards it as a global object due to 
the declaration used:

void __attribute__((visibility("internal"))) thread2(void);

Consequently, the linker complains about this inconsistency (but also seems to 
experience an error generating the error message).

What I see from the mybuild/include/mips/l4/util/thread.h file are two macros 
for defining and declaring thread functions:

- L4UTIL_THREAD_FUNC introduces a global object wrapping the actual function

- L4UTIL_THREAD_STATIC_FUNC introduces a local object wrapping the actual 
function, declaring it at the C level as a global, internal object

Since we are dealing with the output of the latter macro, it seems that there 
are two main alternatives that suppress the error:

- Add a ".global" directive for the introduced wrapper object in the assembly 
language (as is done by the former macro), producing a global but internal 
object

- Declare the object at the C level as a static object, as in...

  static void thread2(void);

Another solution could involve using a C-level wrapper function and including 
assembly language inside that, if necessary. Maybe someone (Sarah?) could say 
what the motivations were for doing it in the current way. My hypothesis is 
that extra instructions get generated for the C functions that are either 
superfluous or harmful, such as accessing the stack, but I would gladly be 
corrected.

Paul

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: MIPS Creator CI20 patches (again)

[Paul Boddie]

On Tuesday 9. January 2018 00.46.53 Adam Lackorzynski wrote:
> On Mon Jan 08, 2018 at 01:14:09 +0100, Paul Boddie wrote:
> > 
> > I'm aiming to follow up with the binutils maintainers about this, but I
> > just wondered if any of this sounded problematic or familiar.
> 
> No, not familiar. It works with the older tool set, i.e. would be
> interesting whether the more recent ones are not ok here or the code
> needs to change.

I posted another message to the Debian bug I filed, but what I did discover 
was that if I wrap the core of the assembly language routine within a C-level 
function, the toolchain doesn't have a problem with the function, even if I 
set the visibility to internal:

void __attribute__((visibility("internal"))) thread2(void)
{
  asm (
".set push; .set noreorder;"
L4UTIL_THREAD_START_SETUP_GP
"la $t9, thread2_worker_function\n"
"  jal $t9 \n"
"   nop\n"
".set pop"
  );
}

So, I am assuming that the compiler gets confused by the freestanding assembly 
language definition of the function, and the object goes missing in some way 
that then leads to the error. Of course, the above introduces other operations 
that are superfluous, but perhaps not harmful, due to the general boilerplate 
included in C-level functions.

Anyway, I'll see if I get any response from the other discussion.

Thanks for responding!

Paul

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: MIPS Creator CI20 patches (again)

[Adam Lackorzynski]

On Mon Jan 08, 2018 at 01:14:09 +0100, Paul Boddie wrote:
> On Monday 8. January 2018 00.37.41 Adam Lackorzynski wrote:
> > 
> > Is it ok if you have visibility("hidden") instead of internal?
> 
> No, it would seem that all other visibility types produce the same error. In 
> fact, the only thing that seems to prevent an error is to qualify the 
> function 
> signature as static, as previously noted:

Alright, strange, but thanks for investigating.

> static void thread2(void);
> 
> Trying other visibility types or just omitting the static qualifier from the 
> above causes the same error, the essence of which is this:
> 
> Can't find matching LO16 reloc against `.text' for R_MIPS_GOT16 at 0x1f8
> 
> So, I guess it is some kind of code generation bug in the toolchain, but it 
> did make me wonder what the L4UTIL_THREAD_STATIC_FUNC macro does and why we 
> get this problem now. It seems like it introduces a wrapper function that 
> sets 
> up the appropriate register for position-independent code (reminiscent of the 
> ci20-gcc-cpload.diff file amongst my patches which does the same for various 
> l4re-core components that won't otherwise work when compiled with GCC).
> 
> And maybe this wrapper function confuses the compiler somehow. However, it 
> doesn't confuse the compiler for the vcpu example where it is also used. So, 
> there might be something else going on as well.
> 
> I'm aiming to follow up with the binutils maintainers about this, but I just 
> wondered if any of this sounded problematic or familiar.

No, not familiar. It works with the older tool set, i.e. would be
interesting whether the more recent ones are not ok here or the code
needs to change.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: MIPS Creator CI20 patches (again)

[Paul Boddie]

On Monday 8. January 2018 00.37.41 Adam Lackorzynski wrote:
> 
> Is it ok if you have visibility("hidden") instead of internal?

No, it would seem that all other visibility types produce the same error. In 
fact, the only thing that seems to prevent an error is to qualify the function 
signature as static, as previously noted:

static void thread2(void);

Trying other visibility types or just omitting the static qualifier from the 
above causes the same error, the essence of which is this:

Can't find matching LO16 reloc against `.text' for R_MIPS_GOT16 at 0x1f8

So, I guess it is some kind of code generation bug in the toolchain, but it 
did make me wonder what the L4UTIL_THREAD_STATIC_FUNC macro does and why we 
get this problem now. It seems like it introduces a wrapper function that sets 
up the appropriate register for position-independent code (reminiscent of the 
ci20-gcc-cpload.diff file amongst my patches which does the same for various 
l4re-core components that won't otherwise work when compiled with GCC).

And maybe this wrapper function confuses the compiler somehow. However, it 
doesn't confuse the compiler for the vcpu example where it is also used. So, 
there might be something else going on as well.

I'm aiming to follow up with the binutils maintainers about this, but I just 
wondered if any of this sounded problematic or familiar.

Paul

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: MIPS Creator CI20 patches (again)

[Adam Lackorzynski]

Hi Paul,

On Sun Jan 07, 2018 at 14:15:13 +0100, Paul Boddie wrote:
> Sorry to follow up on myself again...
> 
> On Thursday 21. December 2017 01.55.51 Paul Boddie wrote:
> > On Wednesday 20. December 2017 16.52.45 Paul Boddie wrote:
> > > However, another problem has emerged when trying to build L4Re. It
> > > appears that something changed between r72 and r73, and now, when I try
> > > and build L4Re, I get a linker error as described in the following
> > > Debian bug report:
> > > 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884821
> > > 
> > > 
> > > mipsel-linux-gnu-ld: main.o: Can't find matching LO16 reloc against
> > > `.text' for R_MIPS_GOT16 at 0x1f8 in section `mipsel-linux-gnu-ld: BFD
> > > (GNU Binutils for Debian) 2.29.1 internal error, aborting at
> > > ../../bfd/bfd.c:866 in _bfd_doprnt
> 
> This specific internal error is a bug in binutils when producing the error 
> message, but the error causing the message is a genuine problem.
> 
> In pkg/examples/sys/utcb-ipc/main.c, expanding the L4UTIL_THREAD_STATIC_FUNC 
> macro by hand, I get the following:
> 
> EXTERN_C_BEGIN
> void __attribute__((visibility("internal"))) thread2(void);
> static void __attribute__((used)) thread2_worker_function(void);
> asm (
>   ".type thread2, function \n"
>   "thread2 : \n .set push; .set noreorder;"
>   L4UTIL_THREAD_START_SETUP_GP
>   "la $t9, thread2_worker_function\n"
>   "  jal $t9 \n"
>   "   nop\n"
>   ".set pop"
> );
> EXTERN_C_END
> static L4_NORETURN void thread2_worker_function(void)
> {
> ...
> }
> 
> It seems that the problem is caused by the declaration of thread2. If I 
> replace that with this...
> 
> static void thread2(void);
> 
> ...the error associated with the output goes away (although I get a warning 
> from the compiler about thread2 not being defined, which happens in the 
> assembly language code, of course). But obviously, this isn't a proper 
> solution.

Is it ok if you have visibility("hidden") instead of internal?


Thanks,
Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: MIPS Creator CI20 patches (again)

[Paul Boddie]

Sorry to follow up on myself again...

On Thursday 21. December 2017 01.55.51 Paul Boddie wrote:
> On Wednesday 20. December 2017 16.52.45 Paul Boddie wrote:
> > However, another problem has emerged when trying to build L4Re. It
> > appears that something changed between r72 and r73, and now, when I try
> > and build L4Re, I get a linker error as described in the following
> > Debian bug report:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884821
> > 
> > 
> > mipsel-linux-gnu-ld: main.o: Can't find matching LO16 reloc against
> > `.text' for R_MIPS_GOT16 at 0x1f8 in section `mipsel-linux-gnu-ld: BFD
> > (GNU Binutils for Debian) 2.29.1 internal error, aborting at
> > ../../bfd/bfd.c:866 in _bfd_doprnt

This specific internal error is a bug in binutils when producing the error 
message, but the error causing the message is a genuine problem.

In pkg/examples/sys/utcb-ipc/main.c, expanding the L4UTIL_THREAD_STATIC_FUNC 
macro by hand, I get the following:

EXTERN_C_BEGIN
void __attribute__((visibility("internal"))) thread2(void);
static void __attribute__((used)) thread2_worker_function(void);
asm (
  ".type thread2, function \n"
  "thread2 : \n .set push; .set noreorder;"
  L4UTIL_THREAD_START_SETUP_GP
  "la $t9, thread2_worker_function\n"
  "  jal $t9 \n"
  "   nop\n"
  ".set pop"
);
EXTERN_C_END
static L4_NORETURN void thread2_worker_function(void)
{
...
}

It seems that the problem is caused by the declaration of thread2. If I 
replace that with this...

static void thread2(void);

...the error associated with the output goes away (although I get a warning 
from the compiler about thread2 not being defined, which happens in the 
assembly language code, of course). But obviously, this isn't a proper 
solution.

Paul

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: MIPS Creator CI20 patches (again)

[Paul Boddie]

On Wednesday 20. December 2017 16.52.45 Paul Boddie wrote:
> 
> However, another problem has emerged when trying to build L4Re. It appears
> that something changed between r72 and r73, and now, when I try and build
> L4Re, I get a linker error as described in the following Debian bug report:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884821
> 
> 
> mipsel-linux-gnu-ld: main.o: Can't find matching LO16 reloc against `.text'
> for R_MIPS_GOT16 at 0x1f8 in section `mipsel-linux-gnu-ld: BFD (GNU
> Binutils for Debian) 2.29.1 internal error, aborting at
> ../../bfd/bfd.c:866 in _bfd_doprnt
> 
> mipsel-linux-gnu-ld: Please report this bug.
> 
> 
> Has anything changed in r73 that might affect the structure of generated
> binaries? The same error can also be reproduced in r74 and r75.

I have narrowed this down to the example in pkg/examples/sys/utcb-ipc. The 
only changes made in r73 are these:



Index: pkg/examples/sys/utcb-ipc/main.c
===
--- pkg/examples/sys/utcb-ipc/main.c(revision 72)
+++ pkg/examples/sys/utcb-ipc/main.c(working copy)
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -46,7 +47,7 @@
 }
 }
 
-static void thread2(void)
+L4UTIL_THREAD_STATIC_FUNC(thread2)
 {
   l4_msgtag_t tag;
   l4_msg_regs_t mr;
@@ -64,6 +65,8 @@
 printf("%c", (char)mr.mr[i]);
   printf("\n");
 }
+
+  __builtin_trap();
 }
 
 int main(void)



Changing the function prototype back to its earlier form seems to prevent the 
error, but I guess this is not what we want to do. It seems very odd that 
similar examples such as pkg/examples/sys/vcpu do not seem to suffer from the 
same problem, however.

Paul

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: MIPS Creator CI20 patches (again)

[Paul Boddie]

On Friday 15. December 2017 20.04.11 Paul Boddie wrote:
> 
> I recently looked at the collection of patches accumulated when trying to
> get the CI20 support to a functioning state, and I think I've brought them
> up to date with the latest upstream repository version (r75). In doing so,
> I've also tried to break them up into distinct parcels of functionality so
> that the less interesting or less relevant patches can be ignored.

Unfortunately, I spoke too soon about bringing these patches up to date for 
two reasons. Firstly, I actually tested their application against r75 and 
there were a couple of problems which I think I have fixed now.

However, another problem has emerged when trying to build L4Re. It appears 
that something changed between r72 and r73, and now, when I try and build 
L4Re, I get a linker error as described in the following Debian bug report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884821


mipsel-linux-gnu-ld: main.o: Can't find matching LO16 reloc against `.text'
for R_MIPS_GOT16 at 0x1f8 in section `mipsel-linux-gnu-ld: BFD (GNU Binutils
for Debian) 2.29.1 internal error, aborting at ../../bfd/bfd.c:866 in
_bfd_doprnt

mipsel-linux-gnu-ld: Please report this bug.


Has anything changed in r73 that might affect the structure of generated 
binaries? The same error can also be reproduced in r74 and r75.

Paul

P.S. A page describing the patches can be found here:

http://www.boddie.org.uk/paul/L4Re-Fiasco.OC.html

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers