elfutils-devel February 2010

elfutils-devel@lists.fedorahosted.org

28 participants
32 discussions

Start a nNew thread

(no subject)
by Lauter 28 Feb '10

28 Feb '10

1 0

A safe/clean way to rebuild the string table?
by Jay Vaughan 24 Feb '10

24 Feb '10

Hi all, I am building an application which utilizes elfutils to add NOTE records to ELF files .. the purpose of this application is to provide a form of 'internal inventory control' over executables being used within our specialized environment, and for that purpose a NOTE record is added to ELF files containing an MD5 sum of various parts of the ELF files themselves. In addition, other information may be attached to these NOTE records in our production line, so I really need to nail down adding NOTES to ELF files programmatically. All has been working fine with this utility program so far, but I have run into some problems with the handling of the string table - namely, where I was once realloc()'ing the string table data buffer and appending my new ".note.MD5" string to the list, and this approach of course is just plain wrong. So my next approach has been to, as I'm iterating through the original ELF file, make a new string table out of the headers for each section, and upon completion (calculation of the to-be-inserted md5 string, construction of a proper NOTE record, attachment of the NOTE to the ELF file, etc.) I then burn the old string table and attach the new one. However, I'm really not sure if this is the safe way to do things, or if there is any other way that I could utilize - its a bit 'dodgy' to me at first blush, because what if there are cases out there in our ELF collection where I somehow mess up the string table, or what about the unspoken cases where a string table is expected to be something that libebl doesn't reproduce - I've already noted that some string tables created through libebl don't exactly 100% match the original ones (such as the ones in my redhat machines libc) due to internal optimization of the string table itself (finding overlaps and not inserting duplicate string values and so on..) I posted about this issue on the elftoolchain-developers list (wrong list) and received this suggestion, with my response: > > > > 1. Calculate the checksum or other stuff of the ELF, construct the Elf Notes > > and then write all the bits to a temporary file, say '/tmp/foo'. > > 2. Execute objcopy to add a .note.MD5 section to the ELF file: > > objcopy --add-section '.note.MD5=/tmp/foo' your_executable > > (objcopy will handle all the string table, section table headers stuff etc) One thing this method doesn't do is properly update the name/namesz and type fields, I have found (correct me if I'm wrong) - so for my purposes it appears that the objcopy technique will not produce an *entirely* valid (to-spec) NOTE record. What I am doing now is using a struct like this in my elfnoter application: #define INTW1X_ELF_SECTION ".note.MD5" #define ELF_TEXT_NAME ".text" #define INTW1X_MD5_NOTE_NAME "w1x_md5" #define INTW1X_MD5_TYPE 1 #define MD5_DESC "deadbeefd00df00ddeadbeefd00df00d" #define MD5_BUF_LEN 33 const struct intw1x_elf_note_md5 local_elf_note_md5 __attribute__ ((section(INTW1X_ELF_SECTION))) = { .elf_note = { .n_namesz = sizeof(INTW1X_MD5_NOTE_NAME), .n_descsz = MD5_BUF_LEN, .n_type = INTW1X_MD5_TYPE }, .name = INTW1X_MD5_NOTE_NAME, .desc = MD5_DESC }; .. then, locating this ELF record internally within my elfnoter app programmatically, and 'injecting' it into the target executable after the md5 string is updated, so that I produce an entirely valid (all fields correct) record in the destination binary. At least the thinking is that inlining the definition of this record means that the final object is going to be as standard as gcc and related tools (linker) is going to make it and thus all I have to do is modify the string and glom the object onto my target ELF binary. This is working, its just a little delicate when it comes to updating the string table, alas. My question to the wise developers on this list is whether or not there is another way to safely add an entry to an existing string table without doing too much create-new/destroy-old processing? I've added the use of libebl to my project, and I'm under way with completing my implementation as described above, but I'd really like some dialog with other ELF hackers on what they think about this method? Is there a cleaner method to update the string table than recreating it completely from scratch? BTW, I plan to release my "ELFNoter" app as GPL when its working/debugged .. I wonder if there is interest in including a working app to attach ELF Notes in the elfutils package? I'd be happy were that the case, to provide this app for review and inclusion - I have seen in my searches that there are other applications for such a utility, so perhaps its worth consideration? -- ; -- Jay Vaughan jay.vaughan(a)thalesgroup.com

1 0

libdw not functioning after rebuild
by Kurt Roeckx 24 Feb '10

24 Feb '10

Hi, When I rebuild libdw and the backends, without any changes to the source, but do not relink something like eu-readelf or eu-objdump, they stop functioning correctly. What I see that happens is that it doesn't know any relocation types anymore, they all change to "<INVALID RELOC>". eu-objdump -d returns: "eu-objdump: cannot disassemble" eu-readelf changes "Machine: AMD x86-64" to "Machine: x86_64". Comparing the libdw.so.1 files only shows a difference in the build-id and what looks like a timestamp in the .rodata section. So I'm wondering if there is some mechanism that is preventing this from working, while I see no reason why this shouldn't work. Kurt

2 2

I would like to do that, thank you
by Sergio Zuniga 21 Feb '10

21 Feb '10

Gen qq eric Via ndr gra Onl tfl ine Pha cdk rmacy Without Pres tbr cription XL on nh line pha zt rmacy is the most reliable me cp dication provider for gen vo eric drugs without prescri lti ption including Gen fy eric Via isf gra. We offer a ch em eap Via dq gra solution to customers around the world. We provide the best no pres jxi cription meds and over 1000 gene qc ric pro shz ducts like C aww ialis, Le nvm vitra, Xeni kh cal, Pro au pecia, Cana kt dian Via da gra and many more. All of our health care products are as effe ne ctive as any other brand name me ozw dications, since they are equ dn ally safe and equally relia pc ble. Many people put their trust in the power of Gen hsu eric Via rj gra and generic pro nig ducts in general, thus, XL onl ccs ine phar orz macy escrow ser zxm vice guarantees that you receive nothing but the best quality and customer se pyg rvice. Buy Via zob gra without pres sh cription and get just what you are looking for from a rel fzm iable onli fuj ne pharm fr acy: superior quality pro wy ducts, unbeatable pr ddl ices, effecti rr veness, saf qs ety, discretion, fast sh uf ipping, and total satisf qv action guara xyn nteed. Via ark gra Our pri npn ce$1.15 Ci pdx alis Our pri lpn ce$1.99 Via liu gra + Ci bsc alis + Lev osb itra Our pri hi ce$119.98 Lev zvu itra Our pri xgs ce$2.35

1 0

Pour des économies d'eau importantes
by ecolead 21 Feb '10

21 Feb '10

1 0

Pour des économies d'eau importantes
by ecolead 21 Feb '10

21 Feb '10

1 0

my new cell phone
by Jefferey Knight 21 Feb '10

21 Feb '10

Gen zne eric Via tdr gra Onl vf ine Pha hlw rmacy Without Pres ig cription XL on ce line pha hc rmacy is the most reliable me gb dication provider for gen fp eric drugs without prescri ydt ption including Gen arn eric Via rpb gra. We offer a ch mz eap Via pv gra solution to customers around the world. We provide the best no pres zb cription meds and over 1000 gene xom ric pro pv ducts like C tk ialis, Le yuq vitra, Xeni dcq cal, Pro nj pecia, Cana za dian Via vx gra and many more. All of our health care products are as effe nyu ctive as any other brand name me rmd dications, since they are equ xe ally safe and equally relia jff ble. Many people put their trust in the power of Gen brm eric Via hj gra and generic pro ir ducts in general, thus, XL onl xx ine phar yy macy escrow ser fn vice guarantees that you receive nothing but the best quality and customer se xc rvice. Buy Via ce gra without pres zz cription and get just what you are looking for from a rel rzz iable onli frh ne pharm ob acy: superior quality pro rk ducts, unbeatable pr mpr ices, effecti we veness, saf rkk ety, discretion, fast sh jrz ipping, and total satisf yd action guara zo nteed. Via bl gra Our pri dvj ce$1.15 Ci lf alis Our pri uih ce$1.99 Via ncy gra + Ci tpq alis + Lev aou itra Our pri yk ce$119.98 Lev zpl itra Our pri oxv ce$2.35

1 0

??????? ??????? ???????. ??? ???
by Lourdes Ray 20 Feb '10

20 Feb '10

ORDER VIAG hxr RA NOW AND SAVE! Free Consultation Always Low Pri gn ces Secure Online Ord lh ering Discr gus eet Packaging Confide cuy ntial Via fa gra Delivered Directly To You Licensed Me eum dical Do nvp ctors Licensed phar qmz macists Re bb ceive your Via ndv gra order in 48 hours -------------------------------------------------------------------------------- Via cs gra is a medic aqm ation used in the treatment of erectile dysf yzh unction. Clini pn cal studies shown that Via qi gra possesses a sig ujr nificant therapeutic effect in more than 88% of men with erectile dysfu bm nction. VIA qd GRA is a pill used to treat erectile dys im function (impotence) in men. It can help many men who have erectile dys yk function get and keep an erection when they become se rm xually excited (stim aaj ulated). Via erk gra Our pri zf ce$1.15 Ci by alis Our pri ra ce$1.99 Via xc gra + Ci odm alis + Lev siv itra Our pri szx ce$119.98 Lev dgr itra Our pri gv ce$2.35

1 0

(no subject)
by Kestler 19 Feb '10

19 Feb '10

1 0

0.145 time?
by Roland McGrath 18 Feb '10

18 Feb '10

I tweaked the backends/ makefile rule to avoid the intermediate-file scenario that seems to trigger the timing-sensitive make -j bug. That make bug was hitting me more frequently now (as Mark noticed) and tripped me up trying to prepare for test builds. (The rules were correct before, but make is buggy.) I hope we won't see any gratuitous lossage like that now. I think Mark has tested things with systemtap. I've just done test scratch builds for Fedora 1[123] and got all green. Unless someone knows of something else outstanding, I think we are ready to release 0.145 about now. Thanks, Roland

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

elfutils-devel February 2010