newlib in cross arm compilers missing nano
How newlib in cross compilers is built at the moment is missing libg_nano and libc_nano. possible other bits too. this is cross-arm-none-newlib-devel this has a consequence not being able to build qmk for example/ also symling to /usr/bin/arm-suse-linux-gnueabi-size seems to miss. this is in cross-arm-binutils Regards, Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
On Thu, 6 May 2021, Alin Marin Elena wrote:
How newlib in cross compilers is built at the moment is missing libg_nano and libc_nano. possible other bits too. this is cross-arm-none-newlib-devel
You can look at the 'newlib' package - it doesn't do anything special so sth special might be needed to build/install those libs.
this has a consequence not being able to build qmk for example/
also symling to /usr/bin/arm-suse-linux-gnueabi-size seems to miss. this is in cross-arm-binutils
Can you file a bugreport? Richard.
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
Thanks Richard, there is something like this https://bugs.gentoo.org/532390 I suspect... links to an older redhat where they discuss this issue. on the first issue I will report the second one Regards, Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Thu, 6 May 2021 at 11:08, Richard Biener <rguenther@suse.de> wrote:
On Thu, 6 May 2021, Alin Marin Elena wrote:
How newlib in cross compilers is built at the moment is missing libg_nano and libc_nano. possible other bits too. this is cross-arm-none-newlib-devel
You can look at the 'newlib' package - it doesn't do anything special so sth special might be needed to build/install those libs.
this has a consequence not being able to build qmk for example/
also symling to /usr/bin/arm-suse-linux-gnueabi-size seems to miss. this is in cross-arm-binutils
Can you file a bugreport?
Richard.
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Donnerstag, 6. Mai 2021 12:19:35 CEST Alin Marin Elena wrote:
Thanks Richard,
there is something like this https://bugs.gentoo.org/532390 I suspect... links to an older redhat where they discuss this issue. on the first issue I will report the second one
Can you try: https://build.opensuse.org/package/show/home:StefanBruens:branches:devel:gcc... newlib Regards, Stefan @Richard - Please add Leap 15.3 to devel:gcc, and accept the Leap 42.3 delete requests, which are pending for 4 months now. -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Hi Stefan, 404... also to try I need the cross-arm version.. Regards, Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Thu, 6 May 2021 at 11:55, Stefan Brüns <stefan.bruens@rwth-aachen.de> wrote:
On Donnerstag, 6. Mai 2021 12:19:35 CEST Alin Marin Elena wrote:
Thanks Richard,
there is something like this https://bugs.gentoo.org/532390 I suspect... links to an older redhat where they discuss this issue. on the first issue I will report the second one
Can you try: https://build.opensuse.org/package/show/home:StefanBruens:branches:devel:gcc... newlib
Regards,
Stefan
@Richard - Please add Leap 15.3 to devel:gcc, and accept the Leap 42.3 delete requests, which are pending for 4 months now.
-- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On Donnerstag, 6. Mai 2021 12:57:33 CEST Alin Marin Elena wrote:
Hi Stefan,
404... also to try I need the cross-arm version..
Use the correct URL. cross-* versions are built as multibuild.
https://build.opensuse.org/package/show/ home:StefanBruens:branches:devel:gcc/newlib
Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Hi Richard, on size the bug reported is here https://bugzilla.opensuse.org/show_bug.cgi?id=1185712 let me know what you think on the nano. Regards, Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Thu, 6 May 2021 at 11:19, Alin Marin Elena <alinm.elena@gmail.com> wrote:
Thanks Richard,
there is something like this https://bugs.gentoo.org/532390 I suspect... links to an older redhat where they discuss this issue. on the first issue I will report the second one
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
On Thu, 6 May 2021 at 11:08, Richard Biener <rguenther@suse.de> wrote:
On Thu, 6 May 2021, Alin Marin Elena wrote:
How newlib in cross compilers is built at the moment is missing libg_nano and libc_nano. possible other bits too. this is cross-arm-none-newlib-devel
You can look at the 'newlib' package - it doesn't do anything special so sth special might be needed to build/install those libs.
this has a consequence not being able to build qmk for example/
also symling to /usr/bin/arm-suse-linux-gnueabi-size seems to miss. this is in cross-arm-binutils
Can you file a bugreport?
Richard.
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Thu, 6 May 2021, Alin Marin Elena wrote:
Thanks Richard,
there is something like this https://bugs.gentoo.org/532390 I suspect... links to an older redhat where they discuss this issue. on the first issue I will report the second one
Hmm, sounds more like an extra feature than integral part of newlib. Also newlib will be only half of the story (I wonder how projects automagically pick up the nano version of libstdc++ ...). That said, it would need somebody who actually makes use of these libs to add this to our newlib since otherwise it will be just untested and not working ... any help appreciated. Richard.
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
On Thu, 6 May 2021 at 11:08, Richard Biener <rguenther@suse.de> wrote:
On Thu, 6 May 2021, Alin Marin Elena wrote:
How newlib in cross compilers is built at the moment is missing libg_nano and libc_nano. possible other bits too. this is cross-arm-none-newlib-devel
You can look at the 'newlib' package - it doesn't do anything special so sth special might be needed to build/install those libs.
this has a consequence not being able to build qmk for example/
also symling to /usr/bin/arm-suse-linux-gnueabi-size seems to miss. this is in cross-arm-binutils
Can you file a bugreport?
Richard.
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
I can tell you how qmk makes use of it.. or better said tmk they pass to the LDFLAGS=--specs=nano if I remove it uses the normal libs but produces some really big binary 129MiB vs 31KiB for me a lot of this is magic, I am just a user. Regards, Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Thu, 6 May 2021 at 12:23, Richard Biener <rguenther@suse.de> wrote:
On Thu, 6 May 2021, Alin Marin Elena wrote:
Thanks Richard,
there is something like this https://bugs.gentoo.org/532390 I suspect... links to an older redhat where they discuss this issue. on the first issue I will report the second one
Hmm, sounds more like an extra feature than integral part of newlib. Also newlib will be only half of the story (I wonder how projects automagically pick up the nano version of libstdc++ ...).
That said, it would need somebody who actually makes use of these libs to add this to our newlib since otherwise it will be just untested and not working ... any help appreciated.
Richard.
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
On Thu, 6 May 2021 at 11:08, Richard Biener <rguenther@suse.de> wrote:
On Thu, 6 May 2021, Alin Marin Elena wrote:
How newlib in cross compilers is built at the moment is missing libg_nano and libc_nano. possible other bits too. this is cross-arm-none-newlib-devel
You can look at the 'newlib' package - it doesn't do anything special so sth special might be needed to build/install those libs.
this has a consequence not being able to build qmk for example/
also symling to /usr/bin/arm-suse-linux-gnueabi-size seems to miss. this is in cross-arm-binutils
Can you file a bugreport?
Richard.
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Thu, 6 May 2021, Alin Marin Elena wrote:
I can tell you how qmk makes use of it.. or better said tmk they pass to the LDFLAGS=--specs=nano
if I remove it uses the normal libs but produces some really big binary 129MiB vs 31KiB
I see. It might be enough to build newlib with -ffunction-sections -fdata-sections (on select platforms), at least it looks like it doesn't do that currently. But then you need to link with -Wl,--gc-sections to get rid of unneeded code. Maybe you can try that by branching newlib and amending CFLAGS="%{optflags}" in the .spec file as CFLAGS="%{optflags} -ffunction-sections -fdata-sections" and see if that helps? Richard.
for me a lot of this is magic, I am just a user.
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
On Thu, 6 May 2021 at 12:23, Richard Biener <rguenther@suse.de> wrote:
On Thu, 6 May 2021, Alin Marin Elena wrote:
Thanks Richard,
there is something like this https://bugs.gentoo.org/532390 I suspect... links to an older redhat where they discuss this issue. on the first issue I will report the second one
Hmm, sounds more like an extra feature than integral part of newlib. Also newlib will be only half of the story (I wonder how projects automagically pick up the nano version of libstdc++ ...).
That said, it would need somebody who actually makes use of these libs to add this to our newlib since otherwise it will be just untested and not working ... any help appreciated.
Richard.
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
On Thu, 6 May 2021 at 11:08, Richard Biener <rguenther@suse.de> wrote:
On Thu, 6 May 2021, Alin Marin Elena wrote:
How newlib in cross compilers is built at the moment is missing libg_nano and libc_nano. possible other bits too. this is cross-arm-none-newlib-devel
You can look at the 'newlib' package - it doesn't do anything special so sth special might be needed to build/install those libs.
this has a consequence not being able to build qmk for example/
also symling to /usr/bin/arm-suse-linux-gnueabi-size seems to miss. this is in cross-arm-binutils
Can you file a bugreport?
Richard.
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
Hi Richard, Stefan is doing that already in his branch once is ready I will try it. I symlinked by hand the missing -size so I shall have all things to test. Regards, Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Thu, 6 May 2021 at 12:45, Richard Biener <rguenther@suse.de> wrote:
On Thu, 6 May 2021, Alin Marin Elena wrote:
I can tell you how qmk makes use of it.. or better said tmk they pass to the LDFLAGS=--specs=nano
if I remove it uses the normal libs but produces some really big binary 129MiB vs 31KiB
I see. It might be enough to build newlib with -ffunction-sections -fdata-sections (on select platforms), at least it looks like it doesn't do that currently. But then you need to link with -Wl,--gc-sections to get rid of unneeded code.
Maybe you can try that by branching newlib and amending CFLAGS="%{optflags}" in the .spec file as CFLAGS="%{optflags} -ffunction-sections -fdata-sections"
and see if that helps?
Richard.
for me a lot of this is magic, I am just a user.
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
On Thu, 6 May 2021 at 12:23, Richard Biener <rguenther@suse.de> wrote:
On Thu, 6 May 2021, Alin Marin Elena wrote:
Thanks Richard,
there is something like this https://bugs.gentoo.org/532390 I suspect... links to an older redhat where they discuss this issue. on the first issue I will report the second one
Hmm, sounds more like an extra feature than integral part of newlib. Also newlib will be only half of the story (I wonder how projects automagically pick up the nano version of libstdc++ ...).
That said, it would need somebody who actually makes use of these libs to add this to our newlib since otherwise it will be just untested and not working ... any help appreciated.
Richard.
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
On Thu, 6 May 2021 at 11:08, Richard Biener <rguenther@suse.de> wrote:
On Thu, 6 May 2021, Alin Marin Elena wrote:
How newlib in cross compilers is built at the moment is missing libg_nano and libc_nano. possible other bits too. this is cross-arm-none-newlib-devel
You can look at the 'newlib' package - it doesn't do anything special so sth special might be needed to build/install those libs.
this has a consequence not being able to build qmk for example/
also symling to /usr/bin/arm-suse-linux-gnueabi-size seems to miss. this is in cross-arm-binutils
Can you file a bugreport?
Richard.
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Donnerstag, 6. Mai 2021 13:23:46 CEST Richard Biener wrote:
On Thu, 6 May 2021, Alin Marin Elena wrote:
Thanks Richard,
there is something like this https://bugs.gentoo.org/532390 I suspect... links to an older redhat where they discuss this issue. on the first issue I will report the second one
Hmm, sounds more like an extra feature than integral part of newlib. Also newlib will be only half of the story (I wonder how projects automagically pick up the nano version of libstdc++ ...).
Tend to disagree here, from nosys.specs:
%{!specs=nano.specs:-lc} %{specs=nano.specs:-lc_nano}
So when you (or some upstream) specify "--specs=nano" with the current newlib package, you will end up with a linker error, you libc_nano does not exist. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Hi Stefan, I got the rpm and installed now seems to work, in the sense I do not get a linker error anymore... however the size of the binary produces is crazy big .rwxr-xr-x 1 134M drFaustroll users 7 May 06:54 -I m65_rev1_uk.bin vs .rwxr-xr-x 1 30k drFaustroll users 7 May 07:05 -I m65_rev1_uk.bin by using the stm32 toolchain.. now since the hex files produced are more or less the same 30K I suspect the issue may be more complex and maybe related to the other bug. Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Thu, 6 May 2021 at 13:25, Stefan Brüns <stefan.bruens@rwth-aachen.de> wrote:
On Donnerstag, 6. Mai 2021 13:23:46 CEST Richard Biener wrote:
On Thu, 6 May 2021, Alin Marin Elena wrote:
Thanks Richard,
there is something like this https://bugs.gentoo.org/532390 I suspect... links to an older redhat where they discuss this issue. on the first issue I will report the second one
Hmm, sounds more like an extra feature than integral part of newlib. Also newlib will be only half of the story (I wonder how projects automagically pick up the nano version of libstdc++ ...).
Tend to disagree here, from nosys.specs:
%{!specs=nano.specs:-lc} %{specs=nano.specs:-lc_nano}
So when you (or some upstream) specify "--specs=nano" with the current newlib package, you will end up with a linker error, you libc_nano does not exist.
Regards,
Stefan
-- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On Fri, 7 May 2021, Alin Marin Elena wrote:
Hi Stefan,
I got the rpm and installed now seems to work, in the sense I do not get a linker error anymore... however the size of the binary produces is crazy big .rwxr-xr-x 1 134M drFaustroll users 7 May 06:54 -I m65_rev1_uk.bin vs .rwxr-xr-x 1 30k drFaustroll users 7 May 07:05 -I m65_rev1_uk.bin by using the stm32 toolchain..
So it might be interesting to compare the final link likes as seen by ld (if you pass -v to the GCC driver you'll see the collect{2,-ld} lines that are roughly equivalent) as well as comparing the set of symbols in the final binary and see which ones are excess. Those can then eventually be traced to the offending library they come from. Richard.
now since the hex files produced are more or less the same 30K I suspect the issue may be more complex and maybe related to the other bug.
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
On Thu, 6 May 2021 at 13:25, Stefan Brüns <stefan.bruens@rwth-aachen.de> wrote:
On Donnerstag, 6. Mai 2021 13:23:46 CEST Richard Biener wrote:
On Thu, 6 May 2021, Alin Marin Elena wrote:
Thanks Richard,
there is something like this https://bugs.gentoo.org/532390 I suspect... links to an older redhat where they discuss this issue. on the first issue I will report the second one
Hmm, sounds more like an extra feature than integral part of newlib. Also newlib will be only half of the story (I wonder how projects automagically pick up the nano version of libstdc++ ...).
Tend to disagree here, from nosys.specs:
%{!specs=nano.specs:-lc} %{specs=nano.specs:-lc_nano}
So when you (or some upstream) specify "--specs=nano" with the current newlib package, you will end up with a linker error, you libc_nano does not exist.
Regards,
Stefan
-- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Freitag, 7. Mai 2021 08:07:18 CEST you wrote:
Hi Stefan,
I got the rpm and installed now seems to work, in the sense I do not get a linker error anymore... however the size of the binary produces is crazy big .rwxr-xr-x 1 134M drFaustroll users 7 May 06:54 -I m65_rev1_uk.bin vs .rwxr-xr-x 1 30k drFaustroll users 7 May 07:05 -I m65_rev1_uk.bin by using the stm32 toolchain..
now since the hex files produced are more or less the same 30K I suspect the issue may be more complex and maybe related to the other bug.
I suspect an incomplete/insufficient linker script, including too much in the binary. Have a look at the size of the sections in the corresponding elf files: $> objdump -h m65_re1_uk.elf If in doubt, post the results on the list. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Hi, so a workaround was to pass this to the linker -Wl,--build-id=none personally I understand little on the side effects of this so I do no know if that can be some default setting in the linker. but with that flag the size is the same as stm32 toolchain. Regards, Alin Regards, Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Fri, 7 May 2021 at 12:35, Stefan Brüns <stefan.bruens@rwth-aachen.de> wrote:
On Freitag, 7. Mai 2021 08:07:18 CEST you wrote:
Hi Stefan,
I got the rpm and installed now seems to work, in the sense I do not get a linker error anymore... however the size of the binary produces is crazy big .rwxr-xr-x 1 134M drFaustroll users 7 May 06:54 -I m65_rev1_uk.bin vs .rwxr-xr-x 1 30k drFaustroll users 7 May 07:05 -I m65_rev1_uk.bin by using the stm32 toolchain..
now since the hex files produced are more or less the same 30K I suspect the issue may be more complex and maybe related to the other bug.
I suspect an incomplete/insufficient linker script, including too much in the binary.
Have a look at the size of the sections in the corresponding elf files: $> objdump -h m65_re1_uk.elf
If in doubt, post the results on the list.
Kind regards,
Stefan
-- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On Fri, 7 May 2021, Alin Marin Elena wrote:
Hi,
so a workaround was to pass this to the linker -Wl,--build-id=none personally I understand little on the side effects of this so I do no know if that can be some default setting in the linker. but with that flag the size is the same as stm32 toolchain.
That's quite unbelievable ... if you can reproduce this and share the linker input files it's worth reporting a bug for. Please provide the output of the linker gcc command with -v appended as well. Richard.
Regards, Alin
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
On Fri, 7 May 2021 at 12:35, Stefan Brüns <stefan.bruens@rwth-aachen.de> wrote:
On Freitag, 7. Mai 2021 08:07:18 CEST you wrote:
Hi Stefan,
I got the rpm and installed now seems to work, in the sense I do not get a linker error anymore... however the size of the binary produces is crazy big .rwxr-xr-x 1 134M drFaustroll users 7 May 06:54 -I m65_rev1_uk.bin vs .rwxr-xr-x 1 30k drFaustroll users 7 May 07:05 -I m65_rev1_uk.bin by using the stm32 toolchain..
now since the hex files produced are more or less the same 30K I suspect the issue may be more complex and maybe related to the other bug.
I suspect an incomplete/insufficient linker script, including too much in the binary.
Have a look at the size of the sections in the corresponding elf files: $> objdump -h m65_re1_uk.elf
If in doubt, post the results on the list.
Kind regards,
Stefan
-- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
Hi Richard, indeed here are my steps git clone -b m65-dev --recurse-submodules https://github.com/alinelena/qmk_firmware.git cd qmk_firmware virtualenv ~/venv/qmk2 source ~/venv/qmk2/bin/activate pip install qmk make m65/rev1:uk .rwxr-xr-x 1 134M drFaustroll users 10 May 13:52 -I m65_rev1_uk.bin now edit keyboards/m65/rev1/rules.mk and add at the end EXTRALDFLAGS = -Wl,--build-id=none make clean .rwxr-xr-x 1 30k drFaustroll users 10 May 13:55 -I m65_rev1_uk.bin there is another option where there is no need for the extra flags make m65/rev1:uk OBJCOPY="arm-none-eabi-objcopy -R .note.gnu.build-id" these are my installed packages i+ | cross-arm-binutils | package | 2.36-410.1 | x86_64 | GNU Compiler Collection container (openSUSE_Factory) i+ | cross-arm-none-gcc11 | package | 11.1.1+git67-91.1 | x86_64 | GNU Compiler Collection container (openSUSE_Factory) i+ | cross-arm-none-newlib-devel | package | 4.1.0-35.1 | x86_64 | rpms i+ | cross-avr-binutils | package | 2.36-409.1 | x86_64 | GNU Compiler Collection container (openSUSE_Factory) i+ | cross-avr-gcc7 | package | 7.5.0+r278197-185.1 | x86_64 | GNU Compiler Collection container (openSUSE_Factory) i had to create by hand the -size link(I already opened a bug on this) ll /usr/bin/arm-none-eabi-size 10/05/21 13:59:18 Permissions Links Size User Group Date Modified Name lrwxrwxrwx 1 36 root root 4 May 23:15 /usr/bin/arm-none-eabi-size -> /usr/bin/arm-suse-linux-gnueabi-size for the big size bin this is the output of you big command objdump -h .build/m65_rev1_uk.elf 10/05/21 14:00:43 .build/m65_rev1_uk.elf: file format elf32-littlearm Sections: Idx Name Size VMA LMA File off Algn 0 .note.gnu.build-id 00000024 00000000 00000000 00010000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .mstack 00000400 20000000 20000000 00030000 2**0 ALLOC 2 .pstack 00000800 20000400 20000400 00030000 2**0 ALLOC 3 .vectors 00000160 08002000 08002000 00012000 2**10 CONTENTS, ALLOC, LOAD, READONLY, CODE 4 .xtors 00000008 08002160 08002160 00012160 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .text 000063d8 08002168 08002168 00012168 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .init 00000004 08008540 08008540 00018540 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 7 .fini 00000004 08008544 08008544 00018544 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 8 .rodata 00000ee0 08008548 08008548 00018548 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .ARM.exidx 00000008 08009428 08009428 00019428 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 10 .data 00000184 20000c00 08009430 00020c00 2**2 CONTENTS, ALLOC, LOAD, DATA 11 .bss 0000086c 20000d88 080095b4 00020d88 2**3 ALLOC 12 .ram0_init 00000000 200015f4 200015f4 00020d84 2**2 CONTENTS 13 .ram0 00000000 200015f4 200015f4 00020d84 2**2 CONTENTS 14 .ram1_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 15 .ram1 00000000 00000000 00000000 00020d84 2**2 CONTENTS 16 .ram2_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 17 .ram2 00000000 00000000 00000000 00020d84 2**2 CONTENTS 18 .ram3_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 19 .ram3 00000000 00000000 00000000 00020d84 2**2 CONTENTS 20 .ram4_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 21 .ram4 00000000 00000000 00000000 00020d84 2**2 CONTENTS 22 .ram5_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 23 .ram5 00000000 00000000 00000000 00020d84 2**2 CONTENTS 24 .ram6_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 25 .ram6 00000000 00000000 00000000 00020d84 2**2 CONTENTS 26 .ram7_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 27 .ram7 00000000 00000000 00000000 00020d84 2**2 CONTENTS 28 .heap 00003a0c 200015f4 200015f4 00030000 2**0 ALLOC 29 .ARM.attributes 0000002f 00000000 00000000 00020d84 2**0 CONTENTS, READONLY 30 .comment 000000bb 00000000 00000000 00020db3 2**0 CONTENTS, READONLY 31 .debug_info 0002adae 00000000 00000000 00020e6e 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 32 .debug_abbrev 0000944c 00000000 00000000 0004bc1c 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 33 .debug_loclists 0000a12a 00000000 00000000 00055068 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 34 .debug_aranges 000015f0 00000000 00000000 0005f198 2**3 CONTENTS, READONLY, DEBUGGING, OCTETS 35 .debug_rnglists 00001a6c 00000000 00000000 00060788 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 36 .debug_line 00012eac 00000000 00000000 000621f4 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 37 .debug_str 00007e1b 00000000 00000000 000750a0 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 38 .debug_frame 000033cc 00000000 00000000 0007cebc 2**2 CONTENTS, READONLY, DEBUGGING, OCTETS 39 .stab 000003fc 00000000 00000000 00080288 2**2 CONTENTS, READONLY, DEBUGGING 40 .stabstr 000000ed 00000000 00000000 00080684 2**0 CONTENTS, READONLY, DEBUGGING 41 .debug_line_str 00000038 00000000 00000000 00080771 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Mon, 10 May 2021 at 08:33, Richard Biener <rguenther@suse.de> wrote:
On Fri, 7 May 2021, Alin Marin Elena wrote:
Hi,
so a workaround was to pass this to the linker -Wl,--build-id=none personally I understand little on the side effects of this so I do no know if that can be some default setting in the linker. but with that flag the size is the same as stm32 toolchain.
That's quite unbelievable ... if you can reproduce this and share the linker input files it's worth reporting a bug for. Please provide the output of the linker gcc command with -v appended as well.
Richard.
Regards, Alin
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
On Fri, 7 May 2021 at 12:35, Stefan Brüns <stefan.bruens@rwth-aachen.de> wrote:
On Freitag, 7. Mai 2021 08:07:18 CEST you wrote:
Hi Stefan,
I got the rpm and installed now seems to work, in the sense I do not get a linker error anymore... however the size of the binary produces is crazy big .rwxr-xr-x 1 134M drFaustroll users 7 May 06:54 -I m65_rev1_uk.bin vs .rwxr-xr-x 1 30k drFaustroll users 7 May 07:05 -I m65_rev1_uk.bin by using the stm32 toolchain..
now since the hex files produced are more or less the same 30K I suspect the issue may be more complex and maybe related to the other bug.
I suspect an incomplete/insufficient linker script, including too much in the binary.
Have a look at the size of the sections in the corresponding elf files: $> objdump -h m65_re1_uk.elf
If in doubt, post the results on the list.
Kind regards,
Stefan
-- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Montag, 10. Mai 2021 15:02:38 CEST you wrote:
Hi Richard,
indeed here are my steps
git clone -b m65-dev --recurse-submodules https://github.com/alinelena/qmk_firmware.git cd qmk_firmware virtualenv ~/venv/qmk2 source ~/venv/qmk2/bin/activate pip install qmk make m65/rev1:uk .rwxr-xr-x 1 134M drFaustroll users 10 May 13:52 -I m65_rev1_uk.bin
now edit keyboards/m65/rev1/rules.mk and add at the end EXTRALDFLAGS = -Wl,--build-id=none make clean .rwxr-xr-x 1 30k drFaustroll users 10 May 13:55 -I m65_rev1_uk.bin
[...] for the big size bin this is the output of you big command
objdump -h .build/m65_rev1_uk.elf 10/05/21 14:00:43
.build/m65_rev1_uk.elf: file format elf32-littlearm
Sections: Idx Name Size VMA LMA File off Algn 0 .note.gnu.build-id 00000024 00000000 00000000 00010000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .mstack 00000400 20000000 20000000 00030000 2**0 ALLOC 2 .pstack 00000800 20000400 20000400 00030000 2**0 ALLOC 3 .vectors 00000160 08002000 08002000 00012000 2**10 CONTENTS, ALLOC, LOAD, READONLY, CODE
Now with this output, the difference is obvious: Your .bin file contains mostly 0-padding (~128MByte), between the .build-id and the real code (starting with the interrupt .vector). The .build-id is tagged as CONTENTS, so it is copied into the bin file. For embedded targets, you *dont* want the build id, at least not at its default location (i.e. before everything else). @Alin - edit your .ld script to omit the .build-id section. @Richard - the Linaro/ARM toolchain omits the .build-id for the embedded targets (like arm-eabi-none) by default. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
On Mon, 10 May 2021, Stefan Brüns wrote:
On Montag, 10. Mai 2021 15:02:38 CEST you wrote:
Hi Richard,
indeed here are my steps
git clone -b m65-dev --recurse-submodules https://github.com/alinelena/qmk_firmware.git cd qmk_firmware virtualenv ~/venv/qmk2 source ~/venv/qmk2/bin/activate pip install qmk make m65/rev1:uk .rwxr-xr-x 1 134M drFaustroll users 10 May 13:52 -I m65_rev1_uk.bin
now edit keyboards/m65/rev1/rules.mk and add at the end EXTRALDFLAGS = -Wl,--build-id=none make clean .rwxr-xr-x 1 30k drFaustroll users 10 May 13:55 -I m65_rev1_uk.bin
[...] for the big size bin this is the output of you big command
objdump -h .build/m65_rev1_uk.elf 10/05/21 14:00:43
.build/m65_rev1_uk.elf: file format elf32-littlearm
Sections: Idx Name Size VMA LMA File off Algn 0 .note.gnu.build-id 00000024 00000000 00000000 00010000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .mstack 00000400 20000000 20000000 00030000 2**0 ALLOC 2 .pstack 00000800 20000400 20000400 00030000 2**0 ALLOC 3 .vectors 00000160 08002000 08002000 00012000 2**10 CONTENTS, ALLOC, LOAD, READONLY, CODE
Now with this output, the difference is obvious:
Your .bin file contains mostly 0-padding (~128MByte), between the .build-id and the real code (starting with the interrupt .vector).
The .build-id is tagged as CONTENTS, so it is copied into the bin file.
For embedded targets, you *dont* want the build id, at least not at its default location (i.e. before everything else).
@Alin - edit your .ld script to omit the .build-id section.
@Richard - the Linaro/ARM toolchain omits the .build-id for the embedded targets (like arm-eabi-none) by default.
Oh, I see. So I suppose +%if 0%{!?gcc_target_arch:1} --enable-linker-build-id \ +%else +%if 0%{?gcc_target_glibc:1} + --enable-linker-build-id \ +%endif +%endif should fix it - disable asking for a build-id from GCC for cross compilers that don't target glibc environments. Pushing that to devel:gcc/gcc11 for now. Richard.
Regards,
Stefan
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Mon, 10 May 2021, Alin Marin Elena wrote:
Hi Richard,
indeed here are my steps
git clone -b m65-dev --recurse-submodules https://github.com/alinelena/qmk_firmware.git cd qmk_firmware virtualenv ~/venv/qmk2 source ~/venv/qmk2/bin/activate pip install qmk make m65/rev1:uk .rwxr-xr-x 1 134M drFaustroll users 10 May 13:52 -I m65_rev1_uk.bin
now edit keyboards/m65/rev1/rules.mk and add at the end EXTRALDFLAGS = -Wl,--build-id=none make clean .rwxr-xr-x 1 30k drFaustroll users 10 May 13:55 -I m65_rev1_uk.bin
there is another option where there is no need for the extra flags make m65/rev1:uk OBJCOPY="arm-none-eabi-objcopy -R .note.gnu.build-id"
these are my installed packages i+ | cross-arm-binutils | package | 2.36-410.1 | x86_64 | GNU Compiler Collection container (openSUSE_Factory) i+ | cross-arm-none-gcc11 | package | 11.1.1+git67-91.1 | x86_64 | GNU Compiler Collection container (openSUSE_Factory) i+ | cross-arm-none-newlib-devel | package | 4.1.0-35.1 | x86_64 | rpms i+ | cross-avr-binutils | package | 2.36-409.1 | x86_64 | GNU Compiler Collection container (openSUSE_Factory) i+ | cross-avr-gcc7 | package | 7.5.0+r278197-185.1 | x86_64 | GNU Compiler Collection container (openSUSE_Factory)
i had to create by hand the -size link(I already opened a bug on this) ll /usr/bin/arm-none-eabi-size 10/05/21 13:59:18 Permissions Links Size User Group Date Modified Name lrwxrwxrwx 1 36 root root 4 May 23:15 /usr/bin/arm-none-eabi-size -> /usr/bin/arm-suse-linux-gnueabi-size
for the big size bin this is the output of you big command
The section sizes do not sum up to 134M but I notice that .debug_info alone is already 175k - bigger than the small binary. So for one that smaller binary seems stripped? But then EXTRALDFLAGS = -Wl,--build-id=none shouldn't change this fact... Richard.
objdump -h .build/m65_rev1_uk.elf 10/05/21 14:00:43
.build/m65_rev1_uk.elf: file format elf32-littlearm
Sections: Idx Name Size VMA LMA File off Algn 0 .note.gnu.build-id 00000024 00000000 00000000 00010000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .mstack 00000400 20000000 20000000 00030000 2**0 ALLOC 2 .pstack 00000800 20000400 20000400 00030000 2**0 ALLOC 3 .vectors 00000160 08002000 08002000 00012000 2**10 CONTENTS, ALLOC, LOAD, READONLY, CODE 4 .xtors 00000008 08002160 08002160 00012160 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .text 000063d8 08002168 08002168 00012168 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .init 00000004 08008540 08008540 00018540 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 7 .fini 00000004 08008544 08008544 00018544 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 8 .rodata 00000ee0 08008548 08008548 00018548 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .ARM.exidx 00000008 08009428 08009428 00019428 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 10 .data 00000184 20000c00 08009430 00020c00 2**2 CONTENTS, ALLOC, LOAD, DATA 11 .bss 0000086c 20000d88 080095b4 00020d88 2**3 ALLOC 12 .ram0_init 00000000 200015f4 200015f4 00020d84 2**2 CONTENTS 13 .ram0 00000000 200015f4 200015f4 00020d84 2**2 CONTENTS 14 .ram1_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 15 .ram1 00000000 00000000 00000000 00020d84 2**2 CONTENTS 16 .ram2_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 17 .ram2 00000000 00000000 00000000 00020d84 2**2 CONTENTS 18 .ram3_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 19 .ram3 00000000 00000000 00000000 00020d84 2**2 CONTENTS 20 .ram4_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 21 .ram4 00000000 00000000 00000000 00020d84 2**2 CONTENTS 22 .ram5_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 23 .ram5 00000000 00000000 00000000 00020d84 2**2 CONTENTS 24 .ram6_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 25 .ram6 00000000 00000000 00000000 00020d84 2**2 CONTENTS 26 .ram7_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 27 .ram7 00000000 00000000 00000000 00020d84 2**2 CONTENTS 28 .heap 00003a0c 200015f4 200015f4 00030000 2**0 ALLOC 29 .ARM.attributes 0000002f 00000000 00000000 00020d84 2**0 CONTENTS, READONLY 30 .comment 000000bb 00000000 00000000 00020db3 2**0 CONTENTS, READONLY 31 .debug_info 0002adae 00000000 00000000 00020e6e 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 32 .debug_abbrev 0000944c 00000000 00000000 0004bc1c 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 33 .debug_loclists 0000a12a 00000000 00000000 00055068 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 34 .debug_aranges 000015f0 00000000 00000000 0005f198 2**3 CONTENTS, READONLY, DEBUGGING, OCTETS 35 .debug_rnglists 00001a6c 00000000 00000000 00060788 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 36 .debug_line 00012eac 00000000 00000000 000621f4 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 37 .debug_str 00007e1b 00000000 00000000 000750a0 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 38 .debug_frame 000033cc 00000000 00000000 0007cebc 2**2 CONTENTS, READONLY, DEBUGGING, OCTETS 39 .stab 000003fc 00000000 00000000 00080288 2**2 CONTENTS, READONLY, DEBUGGING 40 .stabstr 000000ed 00000000 00000000 00080684 2**0 CONTENTS, READONLY, DEBUGGING 41 .debug_line_str 00000038 00000000 00000000 00080771 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
On Mon, 10 May 2021 at 08:33, Richard Biener <rguenther@suse.de> wrote:
On Fri, 7 May 2021, Alin Marin Elena wrote:
Hi,
so a workaround was to pass this to the linker -Wl,--build-id=none personally I understand little on the side effects of this so I do no know if that can be some default setting in the linker. but with that flag the size is the same as stm32 toolchain.
That's quite unbelievable ... if you can reproduce this and share the linker input files it's worth reporting a bug for. Please provide the output of the linker gcc command with -v appended as well.
Richard.
Regards, Alin
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
On Fri, 7 May 2021 at 12:35, Stefan Brüns <stefan.bruens@rwth-aachen.de> wrote:
On Freitag, 7. Mai 2021 08:07:18 CEST you wrote:
Hi Stefan,
I got the rpm and installed now seems to work, in the sense I do not get a linker error anymore... however the size of the binary produces is crazy big .rwxr-xr-x 1 134M drFaustroll users 7 May 06:54 -I m65_rev1_uk.bin vs .rwxr-xr-x 1 30k drFaustroll users 7 May 07:05 -I m65_rev1_uk.bin by using the stm32 toolchain..
now since the hex files produced are more or less the same 30K I suspect the issue may be more complex and maybe related to the other bug.
I suspect an incomplete/insufficient linker script, including too much in the binary.
Have a look at the size of the sections in the corresponding elf files: $> objdump -h m65_re1_uk.elf
If in doubt, post the results on the list.
Kind regards,
Stefan
-- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Montag, 10. Mai 2021 15:37:18 CEST you wrote:
On Mon, 10 May 2021, Alin Marin Elena wrote:
Hi Richard,
The section sizes do not sum up to 134M but I notice that .debug_info alone is already 175k - bigger than the small binary. So for one that smaller binary seems stripped?
It sums up quite well. Alin has been talking about a flat address space binary suitable for flashing, not the elf file. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
Great guys, so we fixed 3 bugs in one go. if you let me know when things are ready for testing I will give them a spin. I see the newlib still did not make it in. Regards, Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Mon, 10 May 2021 at 14:47, Stefan Brüns <stefan.bruens@rwth-aachen.de> wrote:
On Montag, 10. Mai 2021 15:37:18 CEST you wrote:
On Mon, 10 May 2021, Alin Marin Elena wrote:
Hi Richard,
The section sizes do not sum up to 134M but I notice that .debug_info alone is already 175k - bigger than the small binary. So for one that smaller binary seems stripped?
It sums up quite well. Alin has been talking about a flat address space binary suitable for flashing, not the elf file.
Regards,
Stefan
-- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
HI Richard and Stefan, i have updated today and now the size is correct. all we need is the nano newlib in repos and this one fixed https://bugzilla.suse.com/show_bug.cgi?id=1185712 Regards. Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Mon, 10 May 2021 at 15:04, Alin Marin Elena <alinm.elena@gmail.com> wrote:
Great guys,
so we fixed 3 bugs in one go. if you let me know when things are ready for testing I will give them a spin. I see the newlib still did not make it in.
Regards, Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Mon, 10 May 2021 at 14:47, Stefan Brüns <stefan.bruens@rwth-aachen.de> wrote:
On Montag, 10. Mai 2021 15:37:18 CEST you wrote:
On Mon, 10 May 2021, Alin Marin Elena wrote:
Hi Richard,
The section sizes do not sum up to 134M but I notice that .debug_info alone is already 175k - bigger than the small binary. So for one that smaller binary seems stripped?
It sums up quite well. Alin has been talking about a flat address space binary suitable for flashing, not the elf file.
Regards,
Stefan
-- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
On Dienstag, 11. Mai 2021 08:03:05 CEST Alin Marin Elena wrote:
HI Richard and Stefan,
i have updated today and now the size is correct. all we need is the nano newlib in repos and this one fixed https://bugzilla.suse.com/show_bug.cgi?id=1185712
Regards. Alin
I am currently waiting for https://build.opensuse.org/request/show/890957 and https://build.opensuse.org/request/show/890963 to be accepted. As soon as that is completed, I will submit the newlib update. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On Dienstag, 11. Mai 2021 08:14:08 CET Stefan Brüns wrote:
On Dienstag, 11. Mai 2021 08:03:05 CEST Alin Marin Elena wrote:
HI Richard and Stefan,
i have updated today and now the size is correct. all we need is the nano newlib in repos and this one fixed https://bugzilla.suse.com/show_bug.cgi?id=1185712
Regards. Alin
I am currently waiting for https://build.opensuse.org/request/show/890957 and https://build.opensuse.org/request/show/890963 to be accepted.
As soon as that is completed, I will submit the newlib update.
Completely forgot about this one, just submitted an SR: https://build.opensuse.org/request/show/941529 @Alin: can you test if this works as expected? Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
Hi Stefan, installed from your repo and seems to work ok. Thank you! Regards, Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Sun, 19 Dec 2021 at 18:15, Stefan Brüns <stefan.bruens@rwth-aachen.de> wrote:
On Dienstag, 11. Mai 2021 08:14:08 CET Stefan Brüns wrote:
On Dienstag, 11. Mai 2021 08:03:05 CEST Alin Marin Elena wrote:
HI Richard and Stefan,
i have updated today and now the size is correct. all we need is the nano newlib in repos and this one fixed https://bugzilla.suse.com/show_bug.cgi?id=1185712
Regards. Alin
I am currently waiting for https://build.opensuse.org/request/show/890957 and https://build.opensuse.org/request/show/890963 to be accepted.
As soon as that is completed, I will submit the newlib update.
Completely forgot about this one, just submitted an SR:
https://build.opensuse.org/request/show/941529
@Alin: can you test if this works as expected?
Kind regards, Stefan
-- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
participants (3)
-
Alin Marin Elena -
Richard Biener -
Stefan Brüns