Menu
▾
▴
elftoolchain-developers — Discussion on elftoolchain development.
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(10) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(7) |
Jul
(8) |
Aug
(4) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
| 2010 |
Jan
(1) |
Feb
(6) |
Mar
(3) |
Apr
(4) |
May
|
Jun
(4) |
Jul
(4) |
Aug
(4) |
Sep
|
Oct
(6) |
Nov
(1) |
Dec
|
| 2011 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(11) |
Nov
(8) |
Dec
(1) |
| 2012 |
Jan
|
Feb
(6) |
Mar
(3) |
Apr
(6) |
May
|
Jun
|
Jul
(2) |
Aug
(7) |
Sep
(3) |
Oct
|
Nov
(6) |
Dec
(10) |
| 2013 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(20) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(5) |
| 2015 |
Jan
(3) |
Feb
(26) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2016 |
Jan
(2) |
Feb
(1) |
Mar
(3) |
Apr
|
May
(6) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
(6) |
May
(1) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(2) |
Apr
(4) |
May
(1) |
Jun
(20) |
Jul
(7) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
(15) |
Mar
(1) |
Apr
|
May
|
Jun
(4) |
Jul
(3) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
(5) |
May
(4) |
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
| 2023 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
(1) |
| 2025 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Joseph K. <jko...@gm...> - 2025-01-08 11:38:01
|
Hello All, Due to an uptick in moderation load for the elftoolchain-develipers list, I have restricted posting on the list to its members. This should hopefully not be a problem for anyone, as it should be straightforward to subscribe prior to posting. Regards, Joseph Koshy |
|
From: Kazuo K. <ka...@ir...> - 2025-01-06 16:11:22
|
Hi yu shan,
It was when I was working on it a couple days ago.
On Jan 6, 2025, 10:44 AM, at 10:44 AM, yu shan wei <mp...@vi...> wrote:
>r4065, This is not the latest version
>
>
>
>yu shan wei
>
>
>
>
>
>Sender：<ka...@pr...>
>
>Time：Monday, January 6, 2025, 23:05
>
>Recipient：<elf...@li...>
>
>Subject：[Elftoolchain-developers] Build failure (FreeBSD x64 version
>12.4)
>
>
>
>Greetings,
>
>Using clang13 on FreeBSD 12.4 RELEASE, we failed at building libdwarf:
>
>cc -O2 -pipe -g -MD -MF.depend.libdwarf_lineno.o
>-MTlibdwarf_lineno.o -std=gnu99 -Wno-format-zero-length
>-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k
>-W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
>-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch
>-Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline
>-Wnested-externs -Wredundant-decls -Wold-style-definition
>-Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety
>-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
>-Wno-error=unused-but-set-variable -Qunused-arguments -I.
>-I/usr/home/kazuo/devel/elftoolchain-code-r4065-trunk/libdwarf
>-I/usr/home/kazuo/devel/elftoolchain-code-r4065-trunk/libdwarf/../common
>-I/usr/home/kazuo/devel/elftoolchain-code-r4065-trunk/libdwarf/../libelf
>-c libdwarf_lineno.c -o libdwarf_lineno.o
>libdwarf_lineno.c:648:16: error: comparison of integers of different
>signs: 'int' and 'Dwarf_Unsigned' (aka 'unsigned long')
>[-Werror,-Wsign-compare]
> for (i = 0; i < li->li_inclen; i++) {
> ~ ^ ~~~~~~~~~~~~~
>libdwarf_lineno.c:690:16: error: comparison of integers of different
>signs: 'int' and 'Dwarf_Unsigned' (aka 'unsigned long')
>[-Werror,-Wsign-compare]
> for (i = 0; i < li->li_lflen; i++) {
> ~ ^ ~~~~~~~~~~~~
>libdwarf_lineno.c:480:12: error: variable 'ret' is uninitialized when
>used here [-Werror,-Wuninitialized]
> return ret;
> ^~~
>libdwarf_lineno.c:446:32: note: initialize the variable 'ret' to
>silence this warning
> int dwarf_size, fmt, i, j, ret;
> ^
>I can try to get around it by disabling Werror but that looks like a
>big yikes.
>
>
>_______________________________________________
>Elftoolchain-developers mailing list
>Elf...@li...
>https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers
>
>
>
>------------------------------------------------------------------------
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Elftoolchain-developers mailing list
>Elf...@li...
>https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers
|
|
From: <mp...@vi...> - 2025-01-06 15:44:08
|
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office"><head> <title></title> <!--[if !mso]><!--> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <!--<![endif]--> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <style type="text/css"> #outlook a { padding:0; } body { margin:0;padding:0;-webkit-text-size-adjust:100%;-ms-text-size-adjust:100%; } table, td { border-collapse:collapse;mso-table-lspace:0pt;mso-table-rspace:0pt; } img { border:0;line-height:100%; outline:none;text-decoration:none;-ms-interpolation-mode:bicubic; } p { display:block;margin:13px 0; } </style> <!--[if mso]> <noscript> <xml> <o:OfficeDocumentSettings> <o:AllowPNG/> <o:PixelsPerInch>96</o:PixelsPerInch> </o:OfficeDocumentSettings> </xml> </noscript> <![endif]--> <!--[if lte mso 11]> <style type="text/css"> .mj-outlook-group-fix { width:100% !important; } </style> <![endif]--> <!--[if !mso]><!--> <link href="https://fonts.googleapis.com/css?family=Ubuntu:300,400,500,700" rel="stylesheet" type="text/css"> <style type="text/css"> @import url(https://fonts.googleapis.com/css?family=Ubuntu:300,400,500,700); </style> <!--<![endif]--> <style type="text/css"> @media only screen and (min-width:480px) { .mj-column-per-100 { width:100% !important; max-width: 100%; } } </style> <style media="screen and (min-width:480px)"> .moz-text-html .mj-column-per-100 { width:100% !important; max-width: 100%; } </style> <style type="text/css"> </style> <style type="text/css"> </style> </head> <body style="word-spacing:normal;"><style></style> <table width="100%" class="koopage-outer-container" align="left"><tbody><tr><td><div class="koopage-mjml-body" style=""> <!--[if mso | IE]><table border="0" cellpadding="0" cellspacing="0" class="koopage-mjml-section-outlook" role="presentation" style="width:1450px;" width="100%" ><tr><td style="line-height:0px;font-size:0px;mso-line-height-rule:exactly;"><![endif]--> <div class="koopage-mjml-section" style="margin: 0px auto 0px 0px; max-width: 1450px;"> <table align="left" border="0" cellpadding="0" cellspacing="0" role="presentation" style="width:100%;"> <tbody> <tr> <td style="direction: ltr; padding: 0px; text-align: left; font-size: 16px;" align="center"> <!--[if mso | IE]><table role="presentation" border="0" cellpadding="0" cellspacing="0"><tr><td class="koopage-mjml-column-outlook" style="vertical-align:top;width:1450px;" ><![endif]--> <div class="mj-column-per-100 mj-outlook-group-fix koopage-mjml-column" style="text-align: left; direction: ltr; display: inline-block; vertical-align: top; width: 100%; font-size: 16px;"> <table border="0" cellpadding="0" cellspacing="0" role="presentation" style="vertical-align:top;" width="100%"> <tbody> <tr> <td align="left" class="" style="padding: 0px 0px 12px; font-size: 16px; word-break: break-all; text-align: left;"> <div style="font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 13px; line-height: 1; text-align: left; color: rgb(0, 0, 0); margin-left: 0px; text-indent: 0px;"><span style="line-height: 1.5;white-space: pre-wrap;font-weight: 400; font-size: 16px; font-family: Microsoft YaHei; font-style: normal; text-decoration: ; color: #000000;"><span style="background-color: ; padding: 0em; text-decoration: ">r4065, This is not the latest version</span></span></div> </td> </tr> <tr> <td align="left" class="" style="padding: 0px 0px 12px; font-size: 16px; word-break: break-all; text-align: left;"> <div style="font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 13px; line-height: 1; text-align: left; color: rgb(0, 0, 0); margin-left: 0px; text-indent: 0px;"><span style="line-height: 1.5;white-space: pre-wrap;font-weight: 400; font-size: 16px; font-family: Microsoft YaHei; font-style: normal; text-decoration: ; color: #000000;"><span style="background-color: ; padding: 0em; text-decoration: "> </span></span></div> </td> </tr> <tr> <td align="left" class="" style="padding: 0px 0px 12px; font-size: 16px; word-break: break-all; text-align: left;"> <div style="font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 13px; line-height: 1; text-align: left; color: rgb(0, 0, 0); margin-left: 0px; text-indent: 0px;"><span style="line-height: 1.5;white-space: pre-wrap;font-weight: 400; font-size: 16px; font-family: Microsoft YaHei; font-style: normal; text-decoration: ; color: #000000;"><span style="background-color: ; padding: 0em; text-decoration: ">yu shan wei</span></span></div> </td> </tr> <tr> <td align="left" class="" style="padding: 0px 0px 12px; font-size: 16px; word-break: break-all; text-align: left;"> <div style="font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 13px; line-height: 1; text-align: left; color: rgb(0, 0, 0); margin-left: 0px; text-indent: 0px;"><span style="line-height: 1.5;white-space: pre-wrap;font-weight: 400; font-size: 16px; font-family: Microsoft YaHei; font-style: normal; text-decoration: ; color: #000000;"><span style="background-color: ; padding: 0em; text-decoration: "> </span></span></div> </td> </tr> <tr> <td align="left" class="" style="padding: 0px 0px 12px; font-size: 16px; word-break: break-all; text-align: left;"> <div style="font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 13px; line-height: 1; text-align: left; color: rgb(0, 0, 0); margin-left: 0px; text-indent: 0px;"><span style="line-height: 1.5;white-space: pre-wrap;font-weight: 400; font-size: 16px; font-family: Microsoft YaHei; font-style: normal; text-decoration: ; color: #000000;"><span style="background-color: ; padding: 0em; text-decoration: "> </span></span></div> </td> </tr> <tr> <td align="center" class="koo-mjml-horizonRule" style="padding: 0px 0px 20px; font-size: 16px; word-break: break-all; text-align: left;"> <p style="border-top:solid 0.65px lightgrey;font-size:1px;margin:0px auto;width:100%;"> </p> <!--[if mso | IE]><table border="0" cellpadding="0" cellspacing="0" style="border-top:solid 0.65px lightgrey;font-size:1px;margin:0px auto;width:1450px;" role="presentation" width="1450px" ><tr><td style="height:0;line-height:0;"> </td></tr></table><![endif]--> </td> </tr> <tr> <td align="left" class="html-block-paragraph-mail-head" style="padding: 0px 0px 12px; font-size: 16px; word-break: break-all; text-align: left;"> <div style="font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 13px; line-height: 1; text-align: left; color: rgb(0, 0, 0); margin-left: 0px; text-indent: 0px;"><span style="line-height: 1.5;white-space: pre-wrap;font-weight: bold; font-size: 16px; font-family: Microsoft YaHei; font-style: normal; text-decoration: ; color: #000000;"><span style="background-color: ; padding: 0em; text-decoration: ">Sender：</span></span><span style="line-height: 1.5;white-space: pre-wrap;font-weight: 400; font-size: 16px; font-family: Microsoft YaHei; font-style: normal; text-decoration: ; color: #000000;"><span style="background-color: ; padding: 0em; text-decoration: "><ka...@pr...></span></span></div> </td> </tr> <tr> <td align="left" class="html-block-paragraph-mail-head" style="padding: 0px 0px 12px; font-size: 16px; word-break: break-all; text-align: left;"> <div style="font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 13px; line-height: 1; text-align: left; color: rgb(0, 0, 0); margin-left: 0px; text-indent: 0px;"><span style="line-height: 1.5;white-space: pre-wrap;font-weight: bold; font-size: 16px; font-family: Microsoft YaHei; font-style: normal; text-decoration: ; color: #000000;"><span style="background-color: ; padding: 0em; text-decoration: ">Time：</span></span><span style="line-height: 1.5;white-space: pre-wrap;font-weight: 400; font-size: 16px; font-family: Microsoft YaHei; font-style: normal; text-decoration: ; color: #000000;"><span style="background-color: ; padding: 0em; text-decoration: ">Monday, January 6, 2025, 23:05</span></span></div> </td> </tr> <tr> <td align="left" class="html-block-paragraph-mail-head" style="padding: 0px 0px 12px; font-size: 16px; word-break: break-all; text-align: left;"> <div style="font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 13px; line-height: 1; text-align: left; color: rgb(0, 0, 0); margin-left: 0px; text-indent: 0px;"><span style="line-height: 1.5;white-space: pre-wrap;font-weight: bold; font-size: 16px; font-family: Microsoft YaHei; font-style: normal; text-decoration: ; color: #000000;"><span style="background-color: ; padding: 0em; text-decoration: ">Recipient：</span></span><span style="line-height: 1.5;white-space: pre-wrap;font-weight: 400; font-size: 16px; font-family: Microsoft YaHei; font-style: normal; text-decoration: ; color: #000000;"><span style="background-color: ; padding: 0em; text-decoration: "><elf...@li...></span></span></div> </td> </tr> <tr> <td align="left" class="html-block-paragraph-mail-head" style="padding: 0px 0px 12px; font-size: 16px; word-break: break-all; text-align: left;"> <div style="font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 13px; line-height: 1; text-align: left; color: rgb(0, 0, 0); margin-left: 0px; text-indent: 0px;"><span style="line-height: 1.5;white-space: pre-wrap;font-weight: bold; font-size: 16px; font-family: Microsoft YaHei; font-style: normal; text-decoration: ; color: #000000;"><span style="background-color: ; padding: 0em; text-decoration: ">Subject：</span></span><span style="line-height: 1.5;white-space: pre-wrap;font-weight: 400; font-size: 16px; font-family: Microsoft YaHei; font-style: normal; text-decoration: ; color: #000000;"><span style="background-color: ; padding: 0em; text-decoration: ">[Elftoolchain-developers] Build failure (FreeBSD x64 version 12.4)</span></span></div> </td> </tr> <tr> <td align="left" class="" style="padding: 0px 0px 12px; font-size: 16px; word-break: break-all; text-align: left;"> <div style="font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 13px; line-height: 1; text-align: left; color: rgb(0, 0, 0); margin-left: 0px; text-indent: 0px;"><span style="line-height: 1.5;white-space: pre-wrap;font-weight: 400; font-size: 16px; font-family: Microsoft YaHei; font-style: normal; text-decoration: ; color: #000000;"><span style="background-color: ; padding: 0em; text-decoration: "> </span></span></div> </td> </tr> </tbody> </table> </div> <!--[if mso | IE]></td></tr></table><![endif]--> </td> </tr> </tbody> </table> </div> <!--[if mso | IE]></td></tr></table><![endif]--> </div></td></tr></tbody></table> <div style="clear: both"></div>Greetings,<br><br>Using clang13 on FreeBSD 12.4 RELEASE, we failed at building libdwarf:<br><br>cc -O2 -pipe -g -MD -MF.depend.libdwarf_lineno.o -MTlibdwarf_lineno.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments -I. -I/usr/home/kazuo/devel/elftoolchain-code-r4065-trunk/libdwarf -I/usr/home/kazuo/devel/elftoolchain-code-r4065-trunk/libdwarf/../common -I/usr/home/kazuo/devel/elftoolchain-code-r4065-trunk/libdwarf/../libelf -c libdwarf_lineno.c -o libdwarf_lineno.o<br>libdwarf_lineno.c:648:16: error: comparison of integers of different signs: 'int' and 'Dwarf_Unsigned' (aka 'unsigned long') [-Werror,-Wsign-compare]<br> for (i = 0; i < li->li_inclen; i++) {<br> ~ ^ ~~~~~~~~~~~~~<br>libdwarf_lineno.c:690:16: error: comparison of integers of different signs: 'int' and 'Dwarf_Unsigned' (aka 'unsigned long') [-Werror,-Wsign-compare]<br> for (i = 0; i < li->li_lflen; i++) {<br> ~ ^ ~~~~~~~~~~~~<br>libdwarf_lineno.c:480:12: error: variable 'ret' is uninitialized when used here [-Werror,-Wuninitialized]<br> return ret;<br> ^~~<br>libdwarf_lineno.c:446:32: note: initialize the variable 'ret' to silence this warning<br> int dwarf_size, fmt, i, j, ret;<br> ^<br>I can try to get around it by disabling Werror but that looks like a big yikes.<br><br><br>_______________________________________________<br>Elftoolchain-developers mailing list<br>Elf...@li...<br>https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers<br> <table width="100%" class="koopage-outer-container" align="left"><tbody><tr><td><div class="koopage-mjml-body" style=""> <!--[if mso | IE]><table border="0" cellpadding="0" cellspacing="0" class="koopage-mjml-section-outlook" role="presentation" style="width:1450px;" width="100%" ><tr><td style="line-height:0px;font-size:0px;mso-line-height-rule:exactly;"><![endif]--> <div class="koopage-mjml-section" style="margin: 0px auto 0px 0px; max-width: 1450px;"> <table align="left" border="0" cellpadding="0" cellspacing="0" role="presentation" style="width:100%;"> <tbody> <tr> <td style="direction: ltr; padding: 0px; text-align: left; font-size: 16px;" align="center"> <!--[if mso | IE]><table role="presentation" border="0" cellpadding="0" cellspacing="0"><tr><td class="koopage-mjml-column-outlook" style="vertical-align:top;width:1450px;" ><![endif]--> <div class="mj-column-per-100 mj-outlook-group-fix koopage-mjml-column" style="text-align: left; direction: ltr; display: inline-block; vertical-align: top; width: 100%; font-size: 16px;"> <table border="0" cellpadding="0" cellspacing="0" role="presentation" style="vertical-align:top;" width="100%"> <tbody> </tbody> </table> </div> <!--[if mso | IE]></td></tr></table><![endif]--> </td> </tr> </tbody> </table> </div> <!--[if mso | IE]></td></tr></table><![endif]--> </div></td></tr></tbody></table> <div style="clear: both"></div></body></html><!--COMPRESSED_CONTENT:eJzlWO9uGzcSfxVCX5ygorT/d6kmRRskufPhguvFKfIhcAIuOZRYrUgdyY0jB+6D9FMf5D71he4VbriyEjmVDQdtDmdUsqXlkDOc+c0MZ6j3o7BZw2g2klaMxiNhTQATRrNX73cTQYcOcIqH4PxohnR4F77r9NzgZAcqDGxvwY1mpu+68ajlYjl3tjfye+t10NZErnejWZmMR5v4dXFxMf4gf80dnzu+Xuzv0fda4pzIeVYz1VBoWEGLImOUC1VTzqBlImMcIEW2Thv4K+j5Iux0OKDjsX8MHQRAuYp3HiLl2Hhw+yRt5GA+auosmr0n7vhyaktRCNSJPof98VO+0t1mR4lQatPDSdhEQe/R5oPwoujRdgccuSKpyjF5sdCe4J+xgYQFkI4H8IEgyD7CeXF6W/wqqbisM1o0ZU0LkWeU1yqheVOVeSpU0qjk7uC3Z7RH1XjoHRwwmrcsZUkuaZ5xDJqqyilP0orKhlUlq6RIKjY67IybsGyTtJDAM1rKiGWS5bStkoQWSqgiyUsmUnF3sLxFLG564hfckDPQMeJuG3N1ndeyEIymICUtUtlS3racFgxyleeiTPK7GXM3GQ113kjOOU1EndIia4FyWQoqWlC8UZlMRXknjV5Yp89xAe+e992hbFM5AFOK0yqTihZ50VCu6oQiKUmh5FWOWt8WRplxVqm2pazB9CpEltJW1ZhtPGVtKXMU/IVzbLTiuqML4HL0v0i1FXdLv09vbYdwnX5IwhPA/d1//v3zaA/Cq3n6YMnPe7v8du3sjyDCUgffG5gIu/rm9pUiaZu0AczaKpd4pkHZ0kYkDZUtpDF4sQzLPxfyL/QKbsT9mTWSb8bkb9z03G1INSZZkmH1zvJZUt4e+qyBJlGqoqAYw3qVMtoyhL7Isdq0FVNZ+YWbnP836J+D0GuNzDfHPXQqWNuJBdeGSngLnV1jh/Rtp33wE297J0BZN4eJgfAZuZBlSVnlSUlzpgBzgZW0YY3Eo6jkuVJZg23Tn8shJ30bj5Yb3fHqyWF3nJJHve4kUWgSNmzk3lMH8OjkMXlXFbuOlqTZpLh/ew+1aSkklCllTFaYKBxTpmix5aiqpi4hy+s72mMswqp71FmxPGA0qwRnDHvPSpQYlmktaVPmCW2zRDZtCnghqpAtisDVf0GUcZ+5Hz9o3fSb4eMHjwQiOm7maU4Q9p0rIvzk+ZO/P/nu5MkYG77BWSAJD6SNzotsnW7lGXdq9lGeEL/+Qug/MkLXeg2//hJHc0KfPY4Pz55OJKyxfE12nG+iP4ydWJx8cYDog3w4Nz1jhL40lmLqrnig5+As7cDMw4JQ5QPeLimWuoDxaB3yOIvK0Zd+4wOshpzBmEICOGcdfvOuuyJvky1xvCX1pvcgaQy1FYZAXI4CtQjDDjY6JYpaaR+Ru0pcW4355Ch3Omr20gHeRwyN0zgS3Af6r57Hvc9wBURNozviFmc6iMiC7bW0Z/hwQI9BAI+hGgcLjqb2rRdOr0OUoU3ELVqBF0NkxUAEZ/ygh8SrNzcBc1B0kYLJjLtjtCFFaTNcybf272zw2212dr5Fm3g7rMdgcTwyREFh4RBe6rmCsNlKgNU6bGhr5eV4ayVdd72nKPsKzBj5aNNO+CV/9NLDywVtH6iHj0tiGP3zco67eb/CRPMxzOLE8QT/p71304VdwXRogqbDsTO9UhiElUCHezUNrjfL6S7yfif7dDKZYo+1ilj+bkH4jIsJFeTTvBCE2t8Q7ZB+v1k6q4pmllYzMqA6I6gehpT2qKJVJLp6HnMDn6VWChzCSaLr/Ywc4ewR4UaSo8eDzB9MnAF5RO7xJSdH/eWYdJhvR/fJq8sMG2MY4wTd7gWng2ZbH+3eBDOP3NPkIUm+Jpo8QHMoKv9GG4F5jaSvvrpP3h9gvO5NfiKvyU/7r+vwYMkdwqNTfxAc16BRNIhG9gGND4l4hEfXUfy5qTfD6YCnzjkadrYAQ2LukQVCs2/glXWHLPzcN9kenvHr6z9A3CfCX1+PSFHNckTEYDmZkY9GDT+6fYJPsBgb6CARZxEslIQwzA/5Nx582508ChsTtQpjosfkx/GXsJC8HgQeE8ENCXgRQU3nEAgffoMlGmv4BgPcoy2xjl8WRjxr0Q4s8J21S48huATCSavnZIOPfvKxyg8fbz7vNfBc0xCS2NxuOwofblp4uJEfOBYhrP1sOj24YksdPrVRdnrNPWEQhA2T3zZisTu77e8UiVBVIYWgZVNxWiRNQnklC5qkHNKslhxquEP95+nFfwHQsawv--> |
|
From: Kazuo K. <ka...@pr...> - 2025-01-03 04:43:23
|
Greetings,
Using clang13 on FreeBSD 12.4 RELEASE, we failed at building libdwarf:
cc -O2 -pipe -g -MD -MF.depend.libdwarf_lineno.o -MTlibdwarf_lineno.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments -I. -I/usr/home/kazuo/devel/elftoolchain-code-r4065-trunk/libdwarf -I/usr/home/kazuo/devel/elftoolchain-code-r4065-trunk/libdwarf/../common -I/usr/home/kazuo/devel/elftoolchain-code-r4065-trunk/libdwarf/../libelf -c libdwarf_lineno.c -o libdwarf_lineno.o
libdwarf_lineno.c:648:16: error: comparison of integers of different signs: 'int' and 'Dwarf_Unsigned' (aka 'unsigned long') [-Werror,-Wsign-compare]
for (i = 0; i < li->li_inclen; i++) {
~ ^ ~~~~~~~~~~~~~
libdwarf_lineno.c:690:16: error: comparison of integers of different signs: 'int' and 'Dwarf_Unsigned' (aka 'unsigned long') [-Werror,-Wsign-compare]
for (i = 0; i < li->li_lflen; i++) {
~ ^ ~~~~~~~~~~~~
libdwarf_lineno.c:480:12: error: variable 'ret' is uninitialized when used here [-Werror,-Wuninitialized]
return ret;
^~~
libdwarf_lineno.c:446:32: note: initialize the variable 'ret' to silence this warning
int dwarf_size, fmt, i, j, ret;
^
I can try to get around it by disabling Werror but that looks like a big yikes.
|
|
From: Kazuo K. <ka...@pr...> - 2024-12-26 20:57:40
|
Hello, I am an amateur developer from the United States who is currently trying to wrap his head around the terrifying world that is ELF and such. I've been watching this project for a while but after coming to the conclusion that I have very few better options, I wanted to reach out and talk on here a bit. One of the architectures that I work with on a regular basis is SGI/MIPS, especially under IRIX. We are facing a situation where there's few good solutions to building software for IRIX in the near future. The IRIX native system toolchain is closed source and difficult to work with. GNU LD/BFD support has never been very good for the OS and even our best version of binutils has numerous bugs. There are also numerous differences and issues with linking that sometimes need nasty hacks to get around. LLVM/LLVM Utils is unlikely to add support for us even if we have a competent developer due to a lack of corporate sponsorship. I'm currently willing to learn and figure this out but I do need someone who's a little bit more experienced to help guide me in the right direction at times. So what I'm asking is: 1. Will support for mips linker/as be upstreamed if we provide quality code? 2. Will patches for interop with GCC on our platform be considered? 3. Will I face any friction attempting to add support for a 20-plus year old OS that is frozen in time? I'm trying to figure out the best way to go forward with my attempts. Almost nobody in our community actually wants to touch GNU bfd, so I want something that's way less complicated and pain in the ass to deal with. Let me know if this group is amenable to helping me out when the time comes? I'm probably going to start with a mips Linux qemu or something similar, get it building/functioning on there, then add patches that will work for SGI IRIX. Thanks! Kaz Kuroi |
|
From: Haowu G. <ge...@bi...> - 2024-11-20 15:57:06
|
Hello, I have referenced RISC-V and attempted to modify all potentially related files, not just readelf. Could you please help check if there are any inappropriate modifications? The loongarch version of freebsd is not yet available, but we are actively trying to port it. https://github.com/haowuge/freebsd-src/commits/la_readelfV2/ <https://github.com/haowuge/freebsd-src/commits/la_readelfV2/ > Thank you very much. # I am now starting to compile my FreeBSD CURRENT and test if the software works properly. ------------------------------------------------------------------ 发件人：Joseph Koshy <elf...@jk...> 发送时间：2024年11月20日(星期三) 05:37 收件人："葛豪武"<ge...@bi...>; "elftoolchain-developers"<elf...@li...> 主 题：Re: [Elftoolchain-developers] add LoongArch support to elftoolchain Greetings, On 2024-11-19 13:25 Haowu Ge <ge...@bi...> wrote: > Hello, I'm trying to add LoongArch support to elftoolchain. In what way > should I submit the patches? Thank you. The best way would be to file a ticket at SourceForge.Net with your patches. Thanks, Joseph Koshy |
|
From: Haowu G. <ge...@bi...> - 2024-11-20 13:58:19
|
Hello all:
I found that the .bt_byteorder in elf64-riscv-freebsd within libelftc_bfdtarget.c is inconsistent with the information provided in the man3 elftc_bfd_find_target.3 manual page. One of them must be incorrect, but I cannot determine which one is wrong.
libelftc_bfdtarget.c
318 {
319 .bt_name = "elf32-riscv",
320 .bt_type = ETF_ELF,
321 .bt_byteorder = ELFDATA2LSB,
322 .bt_elfclass = ELFCLASS32,
323 .bt_machine = EM_RISCV,
324 },
325
326 {
327 .bt_name = "elf64-riscv",
328 .bt_type = ETF_ELF,
329 .bt_byteorder = ELFDATA2LSB,
330 .bt_elfclass = ELFCLASS64,
331 .bt_machine = EM_RISCV,
332 },
333
334 {
335 .bt_name = "elf64-riscv-freebsd",
336 .bt_type = ETF_ELF,
337 .bt_byteorder = ELFDATA2MSB, <----- here
338 .bt_elfclass = ELFCLASS64,
339 .bt_machine = EM_RISCV,
340 .bt_osabi = ELFOSABI_FREEBSD,
341 },
elftc_bfd_find_target.3
83 .It Li elf32-riscv Ta ELF Ta LSB Ta 32
84 .It Li elf64-riscv Ta ELF Ta LSB Ta 64
85 .It Li elf64-riscv-freebsd Ta ELF Ta LSB Ta 64 <----- here
|
|
From: Joseph K. <elf...@jk...> - 2024-11-19 21:56:21
|
Greetings, On 2024-11-19 13:25 Haowu Ge <ge...@bi...> wrote: > Hello, I'm trying to add LoongArch support to elftoolchain. In what way > should I submit the patches? Thank you. The best way would be to file a ticket at SourceForge.Net with your patches. Thanks, Joseph Koshy |
|
From: Haowu G. <ge...@bi...> - 2024-11-19 13:41:56
|
Hello, I'm trying to add LoongArch support to elftoolchain. In what way should I submit the patches? Thank you. |
|
From: Christos M. <chr...@ma...> - 2023-02-28 15:24:10
|
Fixed broken -wR option, and various memory leaks. Relevant PR: https://reviews.freebsd.org/D38419 --- readelf/readelf.c | 35 ++++++++++++++++++++++++----------- 1 file changed, 24 insertions(+), 11 deletions(-) diff --git a/readelf/readelf.c b/readelf/readelf.c index d3b1bb51..134bf0bf 100644 --- a/readelf/readelf.c +++ b/readelf/readelf.c @@ -4701,8 +4701,10 @@ dump_dwarf_line(struct readelf *re) return; } if (dwarf_attrval_unsigned(die, DW_AT_stmt_list, &offset, - &de) != DW_DLV_OK) + &de) != DW_DLV_OK) { + dwarf_dealloc(re->dbg, die, DW_DLA_DIE); continue; + } length = re->dw_read(d, &offset, 4); if (length == 0xffffffff) { @@ -4713,6 +4715,7 @@ dump_dwarf_line(struct readelf *re) if (length > d->d_size - offset) { warnx("invalid .dwarf_line section"); + dwarf_dealloc(re->dbg, die, DW_DLA_DIE); continue; } @@ -4913,6 +4916,7 @@ dump_dwarf_line(struct readelf *re) } + dwarf_dealloc(re->dbg, die, DW_DLA_DIE); } if (ret == DW_DLV_ERROR) warnx("dwarf_next_cu_header: %s", dwarf_errmsg(de)); @@ -4955,9 +4959,9 @@ dump_dwarf_line_decoded(struct readelf *re) printf("%-37s %11s %s\n", "Filename", "Line Number", "Starting Address"); if (dwarf_srclines(die, &linebuf, &linecount, &de) != DW_DLV_OK) - continue; + goto done; if (dwarf_srcfiles(die, &srcfiles, &srccount, &de) != DW_DLV_OK) - continue; + goto done; for (i = 0; i < linecount; i++) { ln = linebuf[i]; if (dwarf_line_srcfileno(ln, &fn, &de) != DW_DLV_OK) @@ -4971,6 +4975,8 @@ dump_dwarf_line_decoded(struct readelf *re) (uintmax_t) lineaddr); } putchar('\n'); +done: + dwarf_dealloc(re->dbg, die, DW_DLA_DIE); } } @@ -5603,7 +5609,8 @@ dump_dwarf_ranges_foreach(struct readelf *re, Dwarf_Die die, Dwarf_Addr base) Dwarf_Addr base0; Dwarf_Half attr; Dwarf_Signed attr_count, cnt; - Dwarf_Unsigned off, bytecnt; + Dwarf_Unsigned bytecnt; + Dwarf_Off off; int i, j, ret; if ((ret = dwarf_attrlist(die, &attr_list, &attr_count, &de)) != @@ -5620,8 +5627,9 @@ dump_dwarf_ranges_foreach(struct readelf *re, Dwarf_Die die, Dwarf_Addr base) } if (attr != DW_AT_ranges) continue; - if (dwarf_formudata(attr_list[i], &off, &de) != DW_DLV_OK) { - warnx("dwarf_formudata failed: %s", dwarf_errmsg(de)); + if (dwarf_global_formref(attr_list[i], &off, &de) != DW_DLV_OK) { + warnx("dwarf_global_formred failed: %s", + dwarf_errmsg(de)); continue; } if (dwarf_get_ranges(re->dbg, (Dwarf_Off) off, &ranges, &cnt, @@ -5663,6 +5671,8 @@ cont_search: warnx("dwarf_siblingof: %s", dwarf_errmsg(de)); else if (ret == DW_DLV_OK) dump_dwarf_ranges_foreach(re, ret_die, base); + + dwarf_dealloc(re->dbg, die, DW_DLA_DIE); } static void @@ -5966,7 +5976,7 @@ dump_dwarf_frame_section(struct readelf *re, struct section *s, int alt) Dwarf_Small cie_version; Dwarf_Ptr fde_addr, fde_inst, cie_inst; char *cie_aug, c; - int i, eh_frame; + int i, ret, eh_frame; Dwarf_Error de; printf("\nThe section %s contains:\n\n", s->name); @@ -5981,10 +5991,13 @@ dump_dwarf_frame_section(struct readelf *re, struct section *s, int alt) } } else if (!strcmp(s->name, ".eh_frame")) { eh_frame = 1; - if (dwarf_get_fde_list_eh(re->dbg, &cie_list, &cie_count, - &fde_list, &fde_count, &de) != DW_DLV_OK) { - warnx("dwarf_get_fde_list_eh failed: %s", - dwarf_errmsg(de)); + ret = dwarf_get_fde_list_eh(re->dbg, &cie_list, &cie_count, + &fde_list, &fde_count, &de); + if (ret != DW_DLV_OK) { + if (ret == DW_DLV_ERROR) { + warnx("dwarf_get_fde_list_eh failed: %s", + dwarf_errmsg(de)); + } return; } } else -- 2.39.2 |
|
From: Michael F. <mf...@mf...> - 2021-11-01 02:51:12
|
--- Linux 5.14.15 included a patch to fix the issue I posted about several months ago (it now sets the section type before gelf_update_rel[a]), but unfortunately 5.14 introduced a new issue [0] caused by an implicitly created empty Elf_Data. I think this would be more awkward to change in objtool, and it seems reasonable to me that elftoolchain should allow NULL d_buf if d_size is 0. [0] https://github.com/oasislinux/oasis/blob/master/pkg/elftoolchain/patch/0005-Allow-empty-Elf_Data.patch libelf/elf_update.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libelf/elf_update.c b/libelf/elf_update.c index baf64809..4fe663d3 100644 --- a/libelf/elf_update.c +++ b/libelf/elf_update.c @@ -818,6 +818,9 @@ _libelf_write_scn(Elf *e, unsigned char *nf, struct _Elf_Extent *ex) rc = (off_t) (sh_off + d->d_off); + if (d->d_size == 0) + continue; + assert(d->d_buf != NULL); assert(d->d_version == e->e_version); assert(d->d_size % msz == 0); -- 2.32.0 |
|
From: Joseph K. <jk...@us...> - 2021-09-08 20:08:51
|
On Thu, Sep 2, 2021 at 9:43 PM Mark Johnston <ma...@fr...> wrote: > I noticed that elftoolchain utilities are inconsistent with respect to > the exit status when --help is specified. (Some software will test the > status for some reason before proceeding to actually use the utility.) > binutils equivalents consistently exit with status 0, so I expect it > makes sense for elftoolchain to do the same. Changed in r3950, thanks. -- Joseph Koshy | Volunteer Developer, The Elftoolchain Project |
|
From: Mark J. <ma...@fr...> - 2021-09-02 20:43:29
|
Hi,
I noticed that elftoolchain utilities are inconsistent with respect to
the exit status when --help is specified. (Some software will test the
status for some reason before proceeding to actually use the utility.)
binutils equivalents consistently exit with status 0, so I expect it
makes sense for elftoolchain to do the same.
Thanks,
-Mark
diff --git a/addr2line/addr2line.c b/addr2line/addr2line.c
index 80bb753f..be534305 100644
--- a/addr2line/addr2line.c
+++ b/addr2line/addr2line.c
@@ -101,10 +101,10 @@ Usage: %s [options] hexaddress...\n\
-V | --version Print a version identifier and exit.\n"
static void
-usage(void)
+usage(int status)
{
(void) fprintf(stderr, USAGE_MESSAGE, ELFTC_GETPROGNAME());
- exit(1);
+ exit(status);
}
static void
@@ -689,11 +689,11 @@ main(int argc, char **argv)
base = 1;
break;
case 'H':
- usage();
+ usage(0);
case 'V':
version();
default:
- usage();
+ usage(1);
}
}
diff --git a/elfcopy/main.c b/elfcopy/main.c
index 78d5748c..940bfb78 100644
--- a/elfcopy/main.c
+++ b/elfcopy/main.c
@@ -233,7 +233,7 @@ static void set_input_target(struct elfcopy *ecp, const char *target_name);
static void set_osabi(struct elfcopy *ecp, const char *abi);
static void set_output_target(struct elfcopy *ecp, const char *target_name);
static void strip_main(struct elfcopy *ecp, int argc, char **argv);
-static void strip_usage(void);
+static void strip_usage(int status);
/*
* An ELF object usually has a structure described by the
@@ -1185,8 +1185,9 @@ strip_main(struct elfcopy *ecp, int argc, char **argv)
ecp->strip = STRIP_UNNEEDED;
break;
case 'h':
+ strip_usage(EXIT_SUCCESS);
default:
- strip_usage();
+ strip_usage(EXIT_FAILURE);
}
}
@@ -1199,13 +1200,13 @@ strip_main(struct elfcopy *ecp, int argc, char **argv)
lookup_symop_list(ecp, NULL, SYMOP_STRIP) == NULL)
ecp->strip = STRIP_ALL;
if (argc == 0)
- strip_usage();
+ strip_usage(EXIT_FAILURE);
/*
* Only accept a single input file if an output file had been
* specified.
*/
if (outfile != NULL && argc != 1)
- strip_usage();
+ strip_usage(EXIT_FAILURE);
for (i = 0; i < argc; i++)
create_file(ecp, argv[i], outfile);
@@ -1543,10 +1544,10 @@ Usage: %s [options] file...\n\
-X | --discard-locals Remove compiler-generated local symbols.\n"
static void
-strip_usage(void)
+strip_usage(int status)
{
(void) fprintf(stderr, STRIP_USAGE_MESSAGE, ELFTC_GETPROGNAME());
- exit(EXIT_FAILURE);
+ exit(status);
}
static void
diff --git a/size/size.c b/size/size.c
index 4976fceb..aa8a76a8 100644
--- a/size/size.c
+++ b/size/size.c
@@ -104,7 +104,7 @@ static void show_version(void);
static void sysv_header(const char *, Elf_Arhdr *);
static void sysv_footer(void);
static void sysv_calc(Elf *, GElf_Ehdr *, GElf_Shdr *);
-static void usage(void);
+static void usage(int);
static void tbl_new(int);
static void tbl_print(const char *, int);
static void tbl_print_num(uint64_t, enum radix_style, int);
@@ -162,7 +162,7 @@ main(int argc, char **argv)
else {
warnx("unrecognized format \"%s\".",
optarg);
- usage();
+ usage(EXIT_FAILURE);
}
break;
case OPT_RADIX:
@@ -176,7 +176,7 @@ main(int argc, char **argv)
else {
warnx("unsupported radix \"%s\".",
optarg);
- usage();
+ usage(EXIT_FAILURE);
}
break;
default:
@@ -185,9 +185,11 @@ main(int argc, char **argv)
}
break;
case 'h':
+ usage(EXIT_SUCCESS);
+ /* NOTREACHED */
case '?':
default:
- usage();
+ usage(EXIT_FAILURE);
/* NOTREACHED */
}
argc -= optind;
@@ -912,10 +914,10 @@ Usage: %s [options] file ...\n\
-x Equivalent to `--radix=16'.\n"
static void
-usage(void)
+usage(int status)
{
(void) fprintf(stderr, USAGE_MESSAGE, ELFTC_GETPROGNAME());
- exit(EXIT_FAILURE);
+ exit(status);
}
static void
diff --git a/strings/strings.c b/strings/strings.c
index 00e59868..20fb2e67 100644
--- a/strings/strings.c
+++ b/strings/strings.c
@@ -90,7 +90,7 @@ int handle_elf(const char *, int);
int handle_binary(const char *, int);
int find_strings(const char *, off_t, off_t);
void show_version(void);
-void usage(void);
+void usage(int status);
/*
* strings(1) extracts text(contiguous printable characters)
@@ -132,7 +132,7 @@ main(int argc, char **argv)
encoding = ENCODING_32BIT_LITTLE;
encoding_size = 4;
} else
- usage();
+ usage(EXIT_FAILURE);
/* NOTREACHED */
break;
case 'f':
@@ -157,7 +157,7 @@ main(int argc, char **argv)
else if (*optarg == 'x')
radix = RADIX_HEX;
else
- usage();
+ usage(EXIT_FAILURE);
/* NOTREACHED */
break;
case 'v':
@@ -178,9 +178,11 @@ main(int argc, char **argv)
min_len += ch - '0';
break;
case 'h':
+ usage(EXIT_SUCCESS);
+ /* NOTREACHED */
case '?':
default:
- usage();
+ usage(EXIT_FAILURE);
/* NOTREACHED */
}
}
@@ -432,11 +434,11 @@ Usage: %s [options] [file...]\n\
-v | --version Print a version identifier and exit.\n"
void
-usage(void)
+usage(int status)
{
fprintf(stderr, USAGE_MESSAGE, ELFTC_GETPROGNAME());
- exit(EXIT_FAILURE);
+ exit(status);
}
void
|
|
From: Kazuo K. <ka...@ir...> - 2021-06-12 20:42:30
|
Hello there, I'm inquiring to ask if I could entice the developers here to add IRIX support. I am more than interested in doing so myself, but I've not yet fully studied your codebase, so I just wanted to open dialogue and "put the bug in your ear" so to speak. Now, because you may be asking, let me give you the "why": SGI IRIX is a proprietary OS, yes, but I (the admin of IRIXNet) am working on developing continuously for the OS despite its discontinuation. To that end, getting modern UNIX tools such as nm, strip, ar etc. would be nice to replace those on IRIX. IRIX currently would be able to use all of the utils with the exception of ranlib - as those operations of libraries are done transparently by our linker. It may also help with obtaining compatibility on Solaris (IRIX has similarities to Solaris 8 and 9) and other System V ones. Before you ask, I have an SGI IRIX server I am more than happy to provide access to. Please let me know if I can be of assistance. I am currently running my own builds to try and get it working, and if I find any patches that can help them build, I will. Best Regards! Kazuo Kuroi |
|
From: Joseph K. <jk...@us...> - 2021-05-04 18:39:11
|
m.f> Alternatively, an arguably better check is to make sure the Elf_Data
m.f> has d_type == ELF_T_REL(A). What are your thoughts on that?
The suggested change looks cleaner at the first glance, but is also a
change that could break existing code.
This is because elf_newdata(3) initializes the 'd_type' field of the
returned Elf_Data descriptor to 'ELF_T_BYTE'. Applications do need to
override this value eventually, but can currently do so any time
before the call to elf_update(3).
With this change applications would need to set 'd_type' before
calling the gelf_update_rel{,a}() APIs, which is a new behavioral
requirement.
--
Joseph Koshy | Volunteer Developer, The Elftoolchain Project
|
|
From: Michael F. <mf...@mf...> - 2021-05-01 22:00:35
|
Michael Forney <mf...@mf...> wrote:
> I agree that the sanity check is good in general, but I have to
> wonder if it makes sense to fail if the section type is just not
> yet set (SHT_NULL), since that does not necessarily indicate an
> application error.
Alternatively, an arguably better check is to make sure the Elf_Data
has d_type == ELF_T_REL(A). What are your thoughts on that?
diff --git a/libelf/gelf_rel.c b/libelf/gelf_rel.c
index 60332597..3ff48647 100644
--- a/libelf/gelf_rel.c
+++ b/libelf/gelf_rel.c
@@ -42,7 +42,6 @@ gelf_getrel(Elf_Data *ed, int ndx, GElf_Rel *dst)
Elf *e;
size_t msz;
Elf_Scn *scn;
- uint32_t sh_type;
Elf32_Rel *rel32;
Elf64_Rel *rel64;
struct _Libelf_Data *d;
@@ -59,12 +58,7 @@ gelf_getrel(Elf_Data *ed, int ndx, GElf_Rel *dst)
ec = e->e_class;
assert(ec == ELFCLASS32 || ec == ELFCLASS64);
- if (ec == ELFCLASS32)
- sh_type = scn->s_shdr.s_shdr32.sh_type;
- else
- sh_type = scn->s_shdr.s_shdr64.sh_type;
-
- if (_libelf_xlate_shtype(sh_type) != ELF_T_REL) {
+ if (d->d_data.d_type != ELF_T_REL) {
LIBELF_SET_ERROR(ARGUMENT, 0);
return (NULL);
}
@@ -104,7 +98,6 @@ gelf_update_rel(Elf_Data *ed, int ndx, GElf_Rel *dr)
Elf *e;
size_t msz;
Elf_Scn *scn;
- uint32_t sh_type;
Elf32_Rel *rel32;
Elf64_Rel *rel64;
struct _Libelf_Data *d;
@@ -121,12 +114,7 @@ gelf_update_rel(Elf_Data *ed, int ndx, GElf_Rel *dr)
ec = e->e_class;
assert(ec == ELFCLASS32 || ec == ELFCLASS64);
- if (ec == ELFCLASS32)
- sh_type = scn->s_shdr.s_shdr32.sh_type;
- else
- sh_type = scn->s_shdr.s_shdr64.sh_type;
-
- if (_libelf_xlate_shtype(sh_type) != ELF_T_REL) {
+ if (d->d_data.d_type != ELF_T_REL) {
LIBELF_SET_ERROR(ARGUMENT, 0);
return (0);
}
diff --git a/libelf/gelf_rela.c b/libelf/gelf_rela.c
index 40462248..71d7e82a 100644
--- a/libelf/gelf_rela.c
+++ b/libelf/gelf_rela.c
@@ -42,7 +42,6 @@ gelf_getrela(Elf_Data *ed, int ndx, GElf_Rela *dst)
Elf *e;
size_t msz;
Elf_Scn *scn;
- uint32_t sh_type;
Elf32_Rela *rela32;
Elf64_Rela *rela64;
struct _Libelf_Data *d;
@@ -59,12 +58,7 @@ gelf_getrela(Elf_Data *ed, int ndx, GElf_Rela *dst)
ec = e->e_class;
assert(ec == ELFCLASS32 || ec == ELFCLASS64);
- if (ec == ELFCLASS32)
- sh_type = scn->s_shdr.s_shdr32.sh_type;
- else
- sh_type = scn->s_shdr.s_shdr64.sh_type;
-
- if (_libelf_xlate_shtype(sh_type) != ELF_T_RELA) {
+ if (d->d_data.d_type != ELF_T_RELA) {
LIBELF_SET_ERROR(ARGUMENT, 0);
return (NULL);
}
@@ -105,7 +99,6 @@ gelf_update_rela(Elf_Data *ed, int ndx, GElf_Rela *dr)
Elf *e;
size_t msz;
Elf_Scn *scn;
- uint32_t sh_type;
Elf32_Rela *rela32;
Elf64_Rela *rela64;
struct _Libelf_Data *d;
@@ -122,12 +115,7 @@ gelf_update_rela(Elf_Data *ed, int ndx, GElf_Rela *dr)
ec = e->e_class;
assert(ec == ELFCLASS32 || ec == ELFCLASS64);
- if (ec == ELFCLASS32)
- sh_type = scn->s_shdr.s_shdr32.sh_type;
- else
- sh_type = scn->s_shdr.s_shdr64.sh_type;
-
- if (_libelf_xlate_shtype(sh_type) != ELF_T_RELA) {
+ if (d->d_data.d_type != ELF_T_RELA) {
LIBELF_SET_ERROR(ARGUMENT, 0);
return (0);
}
|
|
From: Michael F. <mf...@mf...> - 2021-05-01 20:52:56
|
Thanks for your response. My apologies for the empty subject. I hit
send before realizing I forgot to write one.
Joseph Koshy <jk...@us...> wrote:
> > It appears that elftoolchain has a check[1] in gelf_update_rel[a] to
> > make sure that the section header corresponding to the GElf_Data has
> > the appropriate type, and it fails if not.
>
> Yes, its a sanity check - since using gelf_update_rel{,a}() by mistake
> on data descriptors associated another section type could cause hard
> to diagnose data corruption.
>
> Would it be possible to set the section type in your application
> before using these functions?
Unfortunately it is not my application, but a tool required to build
the Linux kernel. I have written a patch[0] which fixes the issue,
and I can try to submit it upstream.
I agree that the sanity check is good in general, but I have to
wonder if it makes sense to fail if the section type is just not
yet set (SHT_NULL), since that does not necessarily indicate an
application error.
[0] https://github.com/oasislinux/linux/commit/85ca71562234d8e5743cfa241bc3f445b6cc9a05
|
|
From: Joseph K. <jk...@us...> - 2021-05-01 09:19:26
|
> It appears that elftoolchain has a check[1] in gelf_update_rel[a] to
> make sure that the section header corresponding to the GElf_Data has
> the appropriate type, and it fails if not.
Yes, its a sanity check - since using gelf_update_rel{,a}() by mistake
on data descriptors associated another section type could cause hard
to diagnose data corruption.
Would it be possible to set the section type in your application
before using these functions?
Regards,
Joseph Koshy
--
Joseph Koshy | Volunteer Developer, The Elftoolchain Project
|
|
From: Joseph K. <jko...@gm...> - 2021-04-30 20:29:08
|
> This is not allowed by the ISO C grammar. Applied in r3949, thanks! Regards, Joseph Koshy |
|
From: Michael F. <mf...@mf...> - 2021-04-29 20:54:41
|
This is not allowed by the ISO C grammar. --- readelf/readelf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/readelf/readelf.c b/readelf/readelf.c index d3b1bb51..7dafd341 100644 --- a/readelf/readelf.c +++ b/readelf/readelf.c @@ -458,7 +458,7 @@ elf_osabi(unsigned int abi) snprintf(s_abi, sizeof(s_abi), "<unknown: %#x>", abi); return (s_abi); } -}; +} static const char * elf_machine(unsigned int mach) -- 2.31.1 |
|
From: Michael F. <mf...@mf...> - 2021-04-29 20:38:05
|
Hi, I'm looking for some advice for an issue I hit with some recent changes to Linux objtool. Since [0], objtool calls gelf_update_rel[a] to write relocations to newly created sections rather than writing to a raw array of GElf_Rel itself. However, the section header is not updated until later when the ELF file is written back to disk. It appears that elftoolchain has a check[1] in gelf_update_rel[a] to make sure that the section header corresponding to the GElf_Data has the appropriate type, and it fails if not. Is this a bug in objtool using the libelf API incorrectly, or is elftoolchain being a bit too eager in its checks? Perhaps it could skip the check if sh_type == SHT_NULL? Thanks for any help! [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a1a664ece586457e9f7652b0bc5b08386259e358 [1] https://sourceforge.net/p/elftoolchain/code/HEAD/tree/trunk/libelf/gelf_rela.c#l69 |
|
From: Joseph K. <jko...@gm...> - 2021-04-10 22:03:02
|
jens> Has this been discussed before and what are the reasons not to merge jens> with LLVM? Thank you for your email. The licensing, build systems, target platforms and project directions differ for the two projects. These aspects in themselves would preclude a simple project merge. But more importantly, the number of volunteer hours available for coding or project management would remain the same irrespective of the banner under which the volunteer work happens. It is not clear to me how a change of banner would make a difference here. Most open-source projects today are unsustainable for their developers. Please see the following study: Software Below the Poverty Line https://staltz.com/software-below-the-poverty-line.html For some developers their open-source maintainership responsibilities also negatively affect their employability. This is because typical employment contracts assert complete ownership over work by employees (even the employee's free time work). Between two candidates of equal merit, the one requiring no changes to the standard employment contract would be the easier hire. These are some of the reasons why open-source maintainer burnout isn't uncommon. Please see: Burn out and/or quitting open source https://github.com/bzg/opensource-challenges >From what I can see, long running open-source projects tend to fall into one of a few camps: 1. Projects with a corporate core and a transient volunteer base. In these projects a handful of salaried employees maintain project continuity, while the unpaid contributors join, contribute for a few years, and then leave. 2. Projects hosted in academia (i.e. effectively tax-payer funded in some countries), where a steady stream of researchers and students keep the projects going while earning their degrees. 3. Projects whose maintainers willingly take the personal hit, in service to some higher ideology. 4. Free time (hobby) projects, where people write code because they like writing code. Personally speaking, I treat *BSD work as being in category '4'. This means that I prioritize what I personally find to be interesting, given the limited number of volunteer hours available. I am not against working closely with a different project such as LLVM - why duplicate effort after all - but I would not want to take on commitments without also having the ability to deliver them in a timely manner. This means that sustainability would need to be addressed first. Suggestions for improving project sustainability would be welcome. Regards, Joseph Koshy |
|
From: Joseph K. <jk...@us...> - 2021-04-05 07:09:22
|
m.f> 4. This is a bit unrelated to objtool, but I noticed that m.f> elfdefinitions.h contains several enums with values that m.f> are too big for int (specifically, EF_PPC_EMB, SHF_COMDEF, m.f> SHF_MIPS_STRING, SHF_EXCLUDE, SHF_MASKPROC, SHT_LOUSER, and m.f> SHT_HIUSER). The C standard says that all enumerator values m.f> must be representable as int, and have type int. FYI, as of [r3937] these constants use (generated) #defines instead of enumerations. Thank you for pointing out this portability issue. Regards, Joseph Koshy |
|
From: Jens S. <sta...@gm...> - 2021-02-01 09:50:46
|
Dear all, I am using the library part of the elftoolchain together with LLVM for my custom musl/clang based Linux OS (Aalbus), and I think this might be a common use of this project. Since there is a significant overlap between elftoolchain and llvm (for example that both provide replacement utilities for binutils) and I am guessing a significant overlap in downstream users (like FreeBSD), I think it could be a mutually beneficial merger. Especially for you guys since I think being under the LLVM umbrella would mean a lot more eyeballs and mindshare. Has this been discussed before and what are the reasons not to merge with LLVM? I got inspired to ask this question after reading this ClangBuiltLinux issue: https://github.com/ClangBuiltLinux/linux/issues/1019 |
|
From: Ed M. <em...@fr...> - 2020-09-15 15:53:16
|
A patch for this issue is in FreeBSD's review system, available at https://reviews.freebsd.org/D23782. It was started by one of the FreeBSD Foundation's co-op students last term, and he's returned for another internship. Mark and I are iterating on the patch in review now; more eyes on the patch are welcome. We hope it's committable soon. |
