Re: RISC-V BSP memory map

[Sebastian Huber]

On 28/05/18 10:48, Hesham Almatary wrote:

The FE310-G000 has the ROM at 0x2000_ and RAM (DTIM) at 0x8000_.

The FU540-C000 (and Qemu "virt") has the ROM at 0x2000_ and RAM (DDR) at
0x8000_.

So, why is the memory at 0x1000_ and not 0x8000_?


That's basically a hack. The reason is when I tried to change RAM to
0x8000 (above 2GiB), I get relocations errors even when I pass
-mcmodel=medany (riscv-pk and seL4 but they don't use stdlib or
startfiles from gcc). Maybe you can help with that error and suggest a
solution as I don't know?
The errors happen during linking stage of libc and crt* stuff. Please
see error log below:


It looks like there is a blocking issue in the RISC-V tool chain here if 
we want to support 64-bit variants running at 0x8000:


https://sourceware.org/bugzilla/show_bug.cgi?id=23244

--
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

Re: [GSOC] CTF generator configuration files

[Sebastian Huber]

Hello Vidushi,

could you please also work on the user documentation and the use cases. 
I am not an expert in this CTF stuff. Without an introduction in the 
user manual I am pretty helpless. I don't know which tools I have to 
install. I don't know the workflow. I don't know why I need a "CTF 
generator configuration file". I have no time to read all the documents 
here and there. Users have no time and are impatient.


--
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

Re: [PATCH] Updating trace buffer configuration

[Sebastian Huber]

On 29/05/18 17:36, Vidushi Vashishth wrote:

---
  linkers/rtld-trace-buffer.ini | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/linkers/rtld-trace-buffer.ini b/linkers/rtld-trace-buffer.ini
index af9fc31..ee68d55 100644
--- a/linkers/rtld-trace-buffer.ini
+++ b/linkers/rtld-trace-buffer.ini
@@ -26,6 +26,7 @@ buffer-local = " uint8_t* in;"
  header = "#include "
  header = "#include "
  header = "#include "
+header = "#include "
  
  [trace-buffer-tracers]

  code = <<

Could you please change the

struct _Thread_Control

to

Thread_Control

and check if it still works.

In RTEMS, we use typedefs for structures in general.


-  return (tc->current_priority << 8) | tc->real_priority;
+  struct _Thread_Control* tc = _Thread_Get_executing();
+  return (_Thread_Get_priority(tc) << 8) | tc->Real_priority.priority;
  }
  
  static inline uint32_t __rtld_tbg_executing_state(void)


--
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

Re: [GSoC] Ways to make the x86_64 port work with UEFI

[Joel Sherrill]

On Tue, May 29, 2018 at 11:26 AM, Amaan Cheval 
wrote:

> On Tue, May 29, 2018 at 9:28 PM, Amaan Cheval 
> wrote:
> > Noted, thanks a ton for the details! Unrelated to the topic at hand,
> > but out of interest, is this the only reading material for further
> > details? http://ceur-ws.org/Vol-1697/EWiLi16_12.pdf
> >
> > In brief: My tests for keeping a libfake.a (compiled without -fpic)
> > and a loader.so with a user-appXYZ.c have been successful, but I'm not
> > sure if my assumptions hold for all cases. See the details below for
> > more.
> >
> > Next actions:
> > - Read more of Linkers and Loaders since it seems to be the only
> > detailed resource I've found at this point
> > - Experiment with actually using the existing librtems*.a I've got and
> > making them boot as a PE UEFI application image
> >
> > 
> 
> >
> > In more detail:
> >
> > The problem:
> > That UEFI needs a relocatable PE file, i.e. one that can function
> > regardless of the physical address it's loaded at (no virtual
> > addresses that early).
> > To build an ELF of that kind, the resources I've seen all build their
> > source with -fpic, and then use objcopy to convert the ELF into a
> > relocatable PE, with an embedded runtime self-relocator (akin to
> > load-time relocation, if I'm understanding correctly).
> >
> > What Joel suggested seems to be the simplest option - see if not using
> > -fpic for _all_ of RTEMS' build system is fine. I think it might be
> > from some testing, but I'm not sure if this is conclusive since I need
> > to understand the specifics of the entire development process better.
> >
> > So here's my understanding of the situation at the moment:
> >
> > - librtems*.a is made up of object files, compiled without -fpic, and
> > that should be fine because I believe object files will use RIP
> > relative addressing code by default on x64 where it can, and leave the
> > rest for link-time relocations to handle. IF this is true, this works
> > perfectly for us because all memory accesses and jumps/calls are
> > relative.
>

Just to be clear. For Deos, I am compiling all code with -fPIC. This
includes all librtemscpu.a and librtemsbsp.a. When I accidentally
missed an adapter file, that caused an issue.


> >
> > - We can have a loader.c which acts as the core with the efi_main
> > function - compile it with -fpic into loader.so, and then link
> > loader.so, librtems*.a, and user-appXYZ.c together to form a
> > relocatable ELF, then convert it into a PE using objcopy. Note that
> > from what I can tell, the ELF generated from this still has type EXEC,
> > not DYN, according to readelf.
>
> Correction: This was a leftover file that I'd forgotten to take out
> after renaming a target. Sorry about the confusion. Just using the
> "-shared" flag does cause the resulting ELF to be of type DYN.
>
> >
> > The concerns I have are about my assumptions; if GCC generates any
> > code that uses absolute addressing and that is resolved as a link-time
> > relocation, that could be problematic because the final relocatable PE
> > may not match up with the resolved absolute address.
>

The Deos kernel guys had me check readelf on a known good executable
with the ones I was producing. The loadable sections should match up.
For example, on one architecture I missed an alignment in the linkcmds
and on another, an argument hidden in bsp_specs made a section writable
which should have been read-only. Just check what you can with readelf
and objdump section headers.


> >
> > My tests with a fake static archive library, and creating a PE have
> > been successful, but I'm unsure of how to trigger the relocation
> > behavior by the UEFI firmware (i.e. loading the UEFI image at an
> > address other than it's preferred one). One idea is to have a UEFI
> > application image that loads this test UEFI application image through
> > the "LoadImage" function UEFI provides as a service and then to use
> > QEMU's monitor / gdb inspection capabilities to see if the address the
> > image is loaded at genuinely changes.
>

That's the question. Does the executable end up at a reliably known address?


> >
> > If any of you have any resources, that'd be highly appreciated. Some
> > resources I'm using so far are:
> > - https://eli.thegreenplace.net/2011/11/03/position-
> independent-code-pic-in-shared-libraries/
> > - https://eli.thegreenplace.net/2011/08/25/load-time-
> relocation-of-shared-libraries/
> > - https://eli.thegreenplace.net/2012/01/03/understanding-the-
> x64-code-models
> >
> > Sorry about the length of the email!
> >
> > On Fri, May 25, 2018 at 10:51 PM, Joel Sherrill  wrote:
> >>
> >>
> >> On Fri, May 25, 2018, 12:11 PM Amaan Cheval 
> wrote:
> >>>
> >>> Hey! Could you link me to some code that you used for the Deos setup
> >>> you mentioned?
> >>> My understanding is that the -shared option can link static archives
> >>> to create a "shared" library in the 

Re: (release notes generator) Do we need to worry about attachment?

[Chris Johns]

On 30/5/18 5:30 am, Dannie Huang wrote:
> I am now able to grab most of needed information from ticket's page by using
> python (like ticket id, description, comments, etc).

Fantastic.

> There is a place for
> attachment on a ticket's page, do we also need to get the information of
> attached files? If we need to, how can I implement? 

I suggest we include a link a reader of the Release Notes can click on. I
suppose this means recording a link when parsing the data from the feed.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fwd: GDB fails to build with Python 3.7

[Chris Johns]

On 30/5/18 12:44 am, Joel Sherrill wrote:
> Is this the Ubuntu issue reported?

This issue has been around a long time. On Windows I have this comment about 
Python:

https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/windows.py#n136

Chris

> 
> -- Forwarded message -
> From: Phil Muldoon mailto:pmuld...@redhat.com>>
> Date: Tue, May 29, 2018, 6:38 AM
> Subject: GDB fails to build with Python 3.7
> To: mailto:g...@sourceware.org>>
> 
> 
> Currently GDB fails to build with Python 3.7
> 
> https://bugs.python.org/issue33470
> 
> This is because we use an internal Python API:
> 
> #ifdef IS_PY3K
>   gdb_module = PyModule_Create (_GdbModuleDef);
>   /* Add _gdb module to the list of known built-in modules.  */
>   _PyImport_FixupBuiltin (gdb_module, "_gdb");
> #else
>   gdb_module = Py_InitModule ("_gdb", python_GdbMethods);
> #endif
> 
> (the _PyImport_FixupBuiltin in python.c).
> 
> This internal API has been changed. According to the advice of the Python
> maintainers we should never have used it in the first place. I didn't
> add this (at least I don't think I did!), so I'm asking whomever
> authored that code to please change it to be 3.7 compatible. I'm not
> sure what the code achieves so I'm reluctant to touch it in case of
> breakages on platforms I don't have easily access to.
> 
> 
> Cheers
> 
> Phil
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC] CTF generator configuration files

[Gedare Bloom]

Vidushi,

You might find some ideas from the 2016 RTEMS CTF GSoC Project:
 http://rtems-tracing-tweaks.blogspot.com/
 https://github.com/vivek9191/rtems/commits/master
Nothing more recent was done with any success that I know of. I don't
know if anyone ever wrote the configuration needed for babeltrace to
convert rtems trace output into CTF. Much of the previous 2 GSoC
efforts tried to integrate barectf code generation with the
trace/capture code base.

Gedare

On Tue, May 29, 2018 at 1:43 PM, Vidushi Vashishth  wrote:
> Hello!
>
> I am in the process of writing a CTF generator configuration file. This will
> be used in converting trace data into Common Trace Format. I am following
> the flow of events as described in [1] for the conversion process. Have
> there been previous attempts to create CTF generator configuration? Is there
> any change to the CTF conversion process? The wiki page I am referring to
> for this purpose was last updated in 2016 hence I needed to ask this. I have
> followed the documentation provided in [2] and [3] to understand how
> configuration files are written and function. Have I left any relevant
> documentation which could help in this process?
>
> Best,
> Vidushi
>
> References:
> [1] https://devel.rtems.org/wiki/Developer/Tracing
> [2] https://devel.rtems.org/wiki/Developer/Tracing/Trace_Linker
> [3] https://devel.rtems.org/wiki/Developer/Tracing/Trace_Buffering
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[GSOC] CTF generator configuration files

[Vidushi Vashishth]

Hello!

I am in the process of writing a CTF generator configuration file. This
will be used in converting trace data into Common Trace Format. I am
following the flow of events as described in [1] for the conversion
process. Have there been previous attempts to create CTF generator
configuration? Is there any change to the CTF conversion process? The wiki
page I am referring to for this purpose was last updated in 2016 hence I
needed to ask this. I have followed the documentation provided in [2] and
[3] to understand how configuration files are written and function. Have I
left any relevant documentation which could help in this process?

Best,
Vidushi

References:
[1] https://devel.rtems.org/wiki/Developer/Tracing
[2] https://devel.rtems.org/wiki/Developer/Tracing/Trace_Linker
[3] https://devel.rtems.org/wiki/Developer/Tracing/Trace_Buffering
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

(release notes generator) Do we need to worry about attachment?

[Dannie Huang]

Chris,

I am now able to grab most of needed information from ticket's page by
using python (like ticket id, description, comments, etc). There is a place
for attachment on a ticket's page, do we also need to get the information
of attached files? If we need to, how can I implement?

Best,
Dannie
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC] Ways to make the x86_64 port work with UEFI

[Amaan Cheval]

On Tue, May 29, 2018 at 9:28 PM, Amaan Cheval  wrote:
> Noted, thanks a ton for the details! Unrelated to the topic at hand,
> but out of interest, is this the only reading material for further
> details? http://ceur-ws.org/Vol-1697/EWiLi16_12.pdf
>
> In brief: My tests for keeping a libfake.a (compiled without -fpic)
> and a loader.so with a user-appXYZ.c have been successful, but I'm not
> sure if my assumptions hold for all cases. See the details below for
> more.
>
> Next actions:
> - Read more of Linkers and Loaders since it seems to be the only
> detailed resource I've found at this point
> - Experiment with actually using the existing librtems*.a I've got and
> making them boot as a PE UEFI application image
>
> 
>
> In more detail:
>
> The problem:
> That UEFI needs a relocatable PE file, i.e. one that can function
> regardless of the physical address it's loaded at (no virtual
> addresses that early).
> To build an ELF of that kind, the resources I've seen all build their
> source with -fpic, and then use objcopy to convert the ELF into a
> relocatable PE, with an embedded runtime self-relocator (akin to
> load-time relocation, if I'm understanding correctly).
>
> What Joel suggested seems to be the simplest option - see if not using
> -fpic for _all_ of RTEMS' build system is fine. I think it might be
> from some testing, but I'm not sure if this is conclusive since I need
> to understand the specifics of the entire development process better.
>
> So here's my understanding of the situation at the moment:
>
> - librtems*.a is made up of object files, compiled without -fpic, and
> that should be fine because I believe object files will use RIP
> relative addressing code by default on x64 where it can, and leave the
> rest for link-time relocations to handle. IF this is true, this works
> perfectly for us because all memory accesses and jumps/calls are
> relative.
>
> - We can have a loader.c which acts as the core with the efi_main
> function - compile it with -fpic into loader.so, and then link
> loader.so, librtems*.a, and user-appXYZ.c together to form a
> relocatable ELF, then convert it into a PE using objcopy. Note that
> from what I can tell, the ELF generated from this still has type EXEC,
> not DYN, according to readelf.

Correction: This was a leftover file that I'd forgotten to take out
after renaming a target. Sorry about the confusion. Just using the
"-shared" flag does cause the resulting ELF to be of type DYN.

>
> The concerns I have are about my assumptions; if GCC generates any
> code that uses absolute addressing and that is resolved as a link-time
> relocation, that could be problematic because the final relocatable PE
> may not match up with the resolved absolute address.
>
> My tests with a fake static archive library, and creating a PE have
> been successful, but I'm unsure of how to trigger the relocation
> behavior by the UEFI firmware (i.e. loading the UEFI image at an
> address other than it's preferred one). One idea is to have a UEFI
> application image that loads this test UEFI application image through
> the "LoadImage" function UEFI provides as a service and then to use
> QEMU's monitor / gdb inspection capabilities to see if the address the
> image is loaded at genuinely changes.
>
> If any of you have any resources, that'd be highly appreciated. Some
> resources I'm using so far are:
> - 
> https://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/
> - 
> https://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries/
> - https://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models
>
> Sorry about the length of the email!
>
> On Fri, May 25, 2018 at 10:51 PM, Joel Sherrill  wrote:
>>
>>
>> On Fri, May 25, 2018, 12:11 PM Amaan Cheval  wrote:
>>>
>>> Hey! Could you link me to some code that you used for the Deos setup
>>> you mentioned?
>>> My understanding is that the -shared option can link static archives
>>> to create a "shared" library in the sense that it doesn't include the
>>> usual crt0 runtime environment and whatnot, but the code within is
>>> still position-dependent. Given that the PE image that EFI needs is
>>> one that needs to be truly relocatable, this may not work - BUT, I've
>>> only just noticed the ./gnuefi/reloc_x86_64.c file which seems to
>>> handle some kinds of runtime relocations encoded within the converted
>>> PE file, so maybe this will work after all. I'll continue to
>>> investigate and let you know how it goes!
>>
>>
>> Deos isn't a good example except that you can compile with -fPIC and put
>> that code into a static library. Deos is a closed source Level A (man rated
>> flight) ARINC 653 RTOS. It's boot process reads configuration information
>> about each partition and associates .so's with each address space per the
>> configuration. It can't change after that.
>>
>> The RTEMS exe is 

Re: [GSoC] Ways to make the x86_64 port work with UEFI

[Amaan Cheval]

Noted, thanks a ton for the details! Unrelated to the topic at hand,
but out of interest, is this the only reading material for further
details? http://ceur-ws.org/Vol-1697/EWiLi16_12.pdf

In brief: My tests for keeping a libfake.a (compiled without -fpic)
and a loader.so with a user-appXYZ.c have been successful, but I'm not
sure if my assumptions hold for all cases. See the details below for
more.

Next actions:
- Read more of Linkers and Loaders since it seems to be the only
detailed resource I've found at this point
- Experiment with actually using the existing librtems*.a I've got and
making them boot as a PE UEFI application image



In more detail:

The problem:
That UEFI needs a relocatable PE file, i.e. one that can function
regardless of the physical address it's loaded at (no virtual
addresses that early).
To build an ELF of that kind, the resources I've seen all build their
source with -fpic, and then use objcopy to convert the ELF into a
relocatable PE, with an embedded runtime self-relocator (akin to
load-time relocation, if I'm understanding correctly).

What Joel suggested seems to be the simplest option - see if not using
-fpic for _all_ of RTEMS' build system is fine. I think it might be
from some testing, but I'm not sure if this is conclusive since I need
to understand the specifics of the entire development process better.

So here's my understanding of the situation at the moment:

- librtems*.a is made up of object files, compiled without -fpic, and
that should be fine because I believe object files will use RIP
relative addressing code by default on x64 where it can, and leave the
rest for link-time relocations to handle. IF this is true, this works
perfectly for us because all memory accesses and jumps/calls are
relative.

- We can have a loader.c which acts as the core with the efi_main
function - compile it with -fpic into loader.so, and then link
loader.so, librtems*.a, and user-appXYZ.c together to form a
relocatable ELF, then convert it into a PE using objcopy. Note that
from what I can tell, the ELF generated from this still has type EXEC,
not DYN, according to readelf.

The concerns I have are about my assumptions; if GCC generates any
code that uses absolute addressing and that is resolved as a link-time
relocation, that could be problematic because the final relocatable PE
may not match up with the resolved absolute address.

My tests with a fake static archive library, and creating a PE have
been successful, but I'm unsure of how to trigger the relocation
behavior by the UEFI firmware (i.e. loading the UEFI image at an
address other than it's preferred one). One idea is to have a UEFI
application image that loads this test UEFI application image through
the "LoadImage" function UEFI provides as a service and then to use
QEMU's monitor / gdb inspection capabilities to see if the address the
image is loaded at genuinely changes.

If any of you have any resources, that'd be highly appreciated. Some
resources I'm using so far are:
- 
https://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/
- 
https://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries/
- https://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models

Sorry about the length of the email!

On Fri, May 25, 2018 at 10:51 PM, Joel Sherrill  wrote:
>
>
> On Fri, May 25, 2018, 12:11 PM Amaan Cheval  wrote:
>>
>> Hey! Could you link me to some code that you used for the Deos setup
>> you mentioned?
>> My understanding is that the -shared option can link static archives
>> to create a "shared" library in the sense that it doesn't include the
>> usual crt0 runtime environment and whatnot, but the code within is
>> still position-dependent. Given that the PE image that EFI needs is
>> one that needs to be truly relocatable, this may not work - BUT, I've
>> only just noticed the ./gnuefi/reloc_x86_64.c file which seems to
>> handle some kinds of runtime relocations encoded within the converted
>> PE file, so maybe this will work after all. I'll continue to
>> investigate and let you know how it goes!
>
>
> Deos isn't a good example except that you can compile with -fPIC and put
> that code into a static library. Deos is a closed source Level A (man rated
> flight) ARINC 653 RTOS. It's boot process reads configuration information
> about each partition and associates .so's with each address space per the
> configuration. It can't change after that.
>
> The RTEMS exe is mostly linked as normal except to use some arguments to say
> some symbols are from a shared library.
>
> The base address of the exe is that of the provided virtual address space
> with .data and .bss in their respective spaces.
>
> And our entry point is in C so there is no asm before that. Great
> simplification.
>
>>
>> Regarding how TLS differs with PIC - could you elaborate? Is it
>> something we'll need 

Re: [GSoC] Tracing

[Vidushi Vashishth]

Hi!

Just updating that I have sent a patch which fixes the trace buffer
generation. I am now able to generate trace buffers for the fileio sample
testcase. I will begin work on CTF conversion now.

Thanks,
Vidushi

On Tue, May 29, 2018 at 1:00 PM, Vidushi Vashishth 
wrote:

> Hey Sebastian!
>
> Yes I have been working on the trace linker the past week. It is outdated
> and needs improvements. A lot of my work depends on me fixing the trace
> linker. I had informed about this last week during the meeting. I thought I
> would update you as soon as I make progress. Nevertheless the following is
> the status of my work:
>
> 1) Identified problems with the trace linker and working on a patch which
> would fix the trace buffer generation. Using the fileio sample as a
> testcase. I talked to Chris regarding the problems I was facing in the
> process yesterday and am getting close to finishing it.
>
> 2) Collected all the relevant wiki documentation page links about the
> tracing system which would be removed once the user manual is updated.
>
> 3) Installed babeltrace on mac and linux environments and understood its
> working. Once the trace linker is fixed and starts generating trace data it
> would be fed into babeltrace to convert it into CTF.
>
> That's about it.
>
> Best,
> Vidushi
>
> On Tue, May 29, 2018 at 12:37 PM, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello Vidushi,
>>
>> I though you agreed to send a regular status report on Monday? Do you
>> still work on the project?
>>
>> --
>> 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

[PATCH] Updating trace buffer configuration

[Vidushi Vashishth]

---
 linkers/rtld-trace-buffer.ini | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/linkers/rtld-trace-buffer.ini b/linkers/rtld-trace-buffer.ini
index af9fc31..ee68d55 100644
--- a/linkers/rtld-trace-buffer.ini
+++ b/linkers/rtld-trace-buffer.ini
@@ -26,6 +26,7 @@ buffer-local = " uint8_t* in;"
 header = "#include "
 header = "#include "
 header = "#include "
+header = "#include "
 
 [trace-buffer-tracers]
 code = <real_priority;
+  struct _Thread_Control* tc = _Thread_Get_executing();
+  return (_Thread_Get_priority(tc) << 8) | tc->Real_priority.priority;
 }
 
 static inline uint32_t __rtld_tbg_executing_state(void)
-- 
2.7.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: GDB fails to build with Python 3.7

[Joel Sherrill]

Is this the Ubuntu issue reported?

-- Forwarded message -
From: Phil Muldoon 
Date: Tue, May 29, 2018, 6:38 AM
Subject: GDB fails to build with Python 3.7
To: 


Currently GDB fails to build with Python 3.7

https://bugs.python.org/issue33470

This is because we use an internal Python API:

#ifdef IS_PY3K
  gdb_module = PyModule_Create (_GdbModuleDef);
  /* Add _gdb module to the list of known built-in modules.  */
  _PyImport_FixupBuiltin (gdb_module, "_gdb");
#else
  gdb_module = Py_InitModule ("_gdb", python_GdbMethods);
#endif

(the _PyImport_FixupBuiltin in python.c).

This internal API has been changed. According to the advice of the Python
maintainers we should never have used it in the first place. I didn't
add this (at least I don't think I did!), so I'm asking whomever
authored that code to please change it to be 3.7 compatible. I'm not
sure what the code achieves so I'm reluctant to touch it in case of
breakages on platforms I don't have easily access to.


Cheers

Phil
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC] Tracing

[Vidushi Vashishth]

Hey Sebastian!

Yes I have been working on the trace linker the past week. It is outdated
and needs improvements. A lot of my work depends on me fixing the trace
linker. I had informed about this last week during the meeting. I thought I
would update you as soon as I make progress. Nevertheless the following is
the status of my work:

1) Identified problems with the trace linker and working on a patch which
would fix the trace buffer generation. Using the fileio sample as a
testcase. I talked to Chris regarding the problems I was facing in the
process yesterday and am getting close to finishing it.

2) Collected all the relevant wiki documentation page links about the
tracing system which would be removed once the user manual is updated.

3) Installed babeltrace on mac and linux environments and understood its
working. Once the trace linker is fixed and starts generating trace data it
would be fed into babeltrace to convert it into CTF.

That's about it.

Best,
Vidushi

On Tue, May 29, 2018 at 12:37 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Vidushi,
>
> I though you agreed to send a regular status report on Monday? Do you
> still work on the project?
>
> --
> 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

[GSoC] Tracing

[Sebastian Huber]

Hello Vidushi,

I though you agreed to send a regular status report on Monday? Do you 
still work on the project?


--
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